Scribd
Upload
27 views6 pages

SEPM

Uploaded by

muskansahani.cseaiml.amcec
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
27 views6 pages

SEPM

Uploaded by

muskansahani.cseaiml.amcec
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Characteristics of software

1) Software is developed or engineered:

➢ Although some similarities exist between software development and


hardware manufacturing, the two activities are fundamentally different.

➢ In both activities, high quality is achieved through good design.

➢ Both the activities are dependent on people, but the relationship between
people is totally varying.

➢ Software projects cannot be managed if they were manufacturing.


2) Software doesn’t “Wear Out”

➢ In early stage of hardware development process the failure rate is very high
but after correcting defects failure rate gets reduced.

➢ Hardware components suffer from the growing effects of many other


environmental factors. Stated simply, the hardware begins to wear out.

➢ Software is not susceptible to the environmental maladies (extreme


temperature, dusts and vibrations)

The following figure shows the relationship between failure rate and time➢

➢When a hardware component wears out, it is replaced by a spare part. There


are no software spare parts.
However, the implication is clear—the software doesn’t wear out.
3) Most Software is custom
 A software part should be planned and carried out with the goal that it tends
to be reused in various projects
 Today software industry is trying to make library of reusable components.
 In the hardware world, component reuse is a natural part of the engineering
process.

Analysis Rules of Thumb (Arlow and Neustadt)


1. Focus on Visible Requirements: Keep the level of abstraction high, avoid
unnecessary details.
2. Add to Understanding: Each model element should enhance understanding
of the requirements.
3. Delay Nonfunctional Considerations: Focus on problem domain analysis
before addressing infrastructure needs.
4. Minimize Coupling: Represent relationships but strive to reduce high levels
of interconnectedness.
5. Provide Stakeholder Value: Ensure the model is useful to all stakeholders
involved.
6. Simplicity: Keep models simple and avoid unnecessary complexity.

Tasks of Requirements Engineering:


Inception:
• Projects usually begin from a business need or market opportunity.
• Stakeholders define the business case, market scope, and project scope,
initiating discussions with the software engineering team.
Elicitation:
• Involves gathering requirements from customers/users, often
encountering problems of scope, understanding.
• An organized approach to requirements gathering is essential.
Elaboration:
• Filters and expands the information obtained during inception and
elicitation, developing a detailed requirements model.
• Focuses on developing a refined model that identifies software
functions, behaviours, and information.
Negotiation:
• Reconciles conflicts between different stakeholders’ requirements
through prioritization, cost and risk assessment, and iterative
discussions.
Specification:
• Documents requirements in various forms, such as written documents,
graphical models, usage scenarios, prototypes.
• Consistent presentation of requirements is beneficial for clarity.
Validation:
• Technical reviews are conducted to ensure requirements are clear,
complete, and correct, involving a review team of engineers, customers,
users, and stakeholders.
Requirements Management:
• Tracks and controls changes to requirements throughout the project's
life, similar to software configuration management.

Eliciting Requirements
1. Initial Meeting Preparation:
• Attendees: Include both software engineers and stakeholders.
• Rules and Agenda: Establish guidelines for preparation and participation.
• Facilitator: Assign a facilitator to control the meeting.
• Definition Mechanism: Use tools such as worksheets, flip charts, wall
stickers, or electronic platforms (bulletin boards, chat rooms) to organize
and display ideas.
2. Inception Phase:
• Conduct initial Q&A sessions to establish the scope of the problem and
overall perception of a solution.
• Develop a preliminary "product request" document summarizing the
project's aims and initial requirements.
• Distribute the product request to all attendees before the meeting.
3. Requirements Gathering Meeting:
• Before the Meeting: Attendees review the product request and prepare
lists of objects, services, and performance criteria.
• During the Meeting: Present individual lists for each topic area.  Engage
in discussion to refine and achieve a consensus on the lists of objects,
services, and performance criteria.
• Post-Meeting:  Review and refine mini-specifications with all
stakeholders, adding new requirements as necessary.  Maintain an
issues list for unresolved topics

DEVELOPING USE CASES


• Use cases are defined from an actor’s point of view. An actor is a role
that people (users) or devices play as they interact with the software.
The first step in writing a use case is to define the set of “actors” that will
be involved in the story.
• A use case typically tells a story about how an end user interacts with the
system under specific circumstances.
1. Actors:
✓ Definition: Actors are entities that interact with the system,
playing specific roles. These can be people or devices.
✓ Primary Actors: Directly interact with the system to achieve a
goal.
✓ Secondary Actors: Support the system so that primary actors
can perform their roles.
✓ Example: For a home security system, actors might include the
homeowner, setup manager, sensors, and monitoring
subsystem
2. Identifying Actors: Not all actors are identified in the first iteration;
primary actors are identified early, and secondary actors are added as
understanding of the system evolves.
3. Developing Use Cases:
✓ Questions to Answer:  Who are the primary and secondary
actors?
 What are the actors’ goals?
 What preconditions should exist?
 What tasks or functions do the actors perform?
 What exceptions might occur?
 What variations in interactions are possible?
 What information does the actor acquire, produce, or
change?
 How does the actor inform the system about changes?
 Does the actor need to be informed about unexpected
changes?
4. Example Use Case:
✓ SafeHome System Actors: Homeowner, Setup Manager,
Sensors , Monitoring Subsystem
✓ Homeowner Interactions: Entering a password , Pressing the
panic button, Activating/deactivating the system
Benefits of Use Cases
1. User-Centric Design
2. Clear Requirement Communication
3. Easily Understandable
4. Guidance for Devewlopment and Testing
5. Supports Incremental Development
6. Improves Traceability

You might also like