Module III
Requirement Engineering
Requirements Engineering
Requirement: A function, constraint or other property that the system must provide to fill the
needs of the systems intended user(s)
Engineering: implies that systematic and repeatable techniques should be used
Requirement Engineering means that requirements for a product are defined, managed and
tested systematically
It is essential that the software engineering team understand the requirements of a problem
before the team tries to solve the problem.
In some cases requirements engineering may be reduced, but it is never abandoned.
RE is software engineering actions that start with communication activity and continues into
the modeling activity.
RE establishes a solid base for design and construction. Without it, resulting software has a
high probability of not meeting customer needs.
Characteristics of a Good Requirement
Clear and Unambiguous
Standard structure
Has only one possible interpretation
Not more than one requirement in one sentence
Correct
A requirement contributes to a real need
Understandable
A reader can easily understand the meaning of the requirement
Verifiable
A requirement can be tested
Complete
Consistent
Traceable
Why is Getting Good Requirements Hard?
Stakeholders dont know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the system requirements.
The requirements change during the RE process. New stakeholders may emerge and the
business environment change.
Requirements Engineering Tasks
Inception: Establish a basic understanding of the problem and the nature of the solution.
Elicitation: Draw out the requirements from stakeholders.
Elaboration (Highly structured): Create an analysis model that represents information,
functional, and behavioral aspects of the requirements.
Negotiation: Agree on a deliverable system that is realistic for developers and customers.
Specification: Describe the requirements formally or informally.
Validation: Review the requirement specification for errors, ambiguities, omissions, and
conflicts.
Requirements management: Manage changing requirements.
Identify
Control
Track Requirements
Changes to Requirements
Inception
Inception Ask context-free questions that establish
Basic understanding of the problem
The people who want a solution
The nature of the solution that is desired, and
The effectiveness of preliminary communication and collaboration between the
customer and the developer
Elicitation
Elicitation - elicit requirements from customers, users and others.
Find out from customers, users and others what the product objectives are
what is to be done
how the product fits into business needs, and
how the product is used on a day to day basis
Elaboration
Focuses on developing a refined technical model of software functions, features, and
constraints using the information obtained during inception and elicitation
Create an analysis model that identifies data, function and behavioral requirements.
It is driven by the creation and refinement of user scenarios that describe how the end-user
will interact with the system.
Each event parsed into extracted.
End result defines informational, functional and behavioral domain of the problem
Negotiation
Negotiation - agree on a deliverable system that is realistic for developers and customers
Requirements are categorized and organized into subsets
Relations among requirements identified
Requirements reviewed for correctness
Requirements prioritized based on customer needs
Negotiation about requirements, project cost and project timeline.
There should be no winner and no loser in effective negotiation.
Specification
Specification Different things to different people.
It can be
Written Document
A set of graphical models,
A formal mathematical models
Collection of usage scenario.
A prototype
Combination of above.
The Formality and format of a specification varies with the size and the complexity of the
software to be built.
For large systems, written document, language descriptions, and graphical models may be the
best approach.
For small systems or products, usage scenarios
Validation
Requirements Validation - formal technical review mechanism that looks for
Errors in content or interpretation
Areas where clarification may be required
Missing information
Inconsistencies (a major problem when large products or systems are engineered)
Conflicting or unrealistic (unachievable) requirements.
Requirement Management
Set of activities that help project team to identify, control, and track requirements and
changes as project proceeds
Requirements begin with identification. Each requirement is assigned a unique
identifier. Once requirement have been identified, traceability table are developed.
Traceability Table:
Features traceability table - shows how requirements relate to customer observable
features
Source traceability table - identifies source of each requirement
Dependency traceability table - indicate relations among requirements
Subsystem traceability table - requirements categorized by subsystem
Interface traceability table - shows requirement relations to internal and external
interfaces
It will help to track, if change in one requirement will affect different aspects of the system.
Initiating Requirements Engineering Process
Identify stakeholders
Stakeholder can be anyone who benefits in a direct or indirect way from the system
which is being developed
Ex. Business manager, project manager, marketing people, software engineer, support engineer, end-
users, internal-external customers, consultants, maintenance engineer.
Each one of them has different view of the system.
Recognize multiple points of view
Marketing group concern about feature and function to excite potential market. To
sell easily in the market.
Business manager concern about feature built within budget and will be ready to meet
market.
End user Easy to learn and use.
SE product functioning at various infrastructure support.
Support engineer Maintainability of software.
Role of RE is to categorize all stakeholder information in a way that there could be no inconsistent or
conflict requirement with one another
Work toward collaboration
RE identify areas of commonality (i.e. Agreed requirement) and areas of conflict or
inconsistency.
It does not mean requirement defined by committee. It may happened they providing
just view of their requirement.
Business manager or senior technologist may make final decision.
Asking the first questions
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution
Is there another source for the solution that you need?
These questions will help stakeholder interest in the software & measurable benefit of successful
implementation.
Asking the question
Next set of questions better understanding of the problem.
What business problem (s) will this solution address?
Describe business environment in which the solution will be used?
Will performance or productivity issues affect the solution is approached?
Final set of questions Effectiveness of communication
Are my questions relevant to the problem?
Am I asking too many questions?
Can anyone else provide additional information?
Should I be asking you anything else?
Eliciting Requirement
Approach for eliciting requirement:
Collaborative Requirement Gathering
Quality Function Deployment
User Scenarios
Elicitation Work Products
Collaborative Requirement Gathering
Team of stakeholders and developers work together to;
Identify the problem
Propose the elements of the solution
Negotiate different approaches
Specify a preliminary set of solution requirements
Basic Guidelines
Meetings are attended by all interested stakeholders.
Rules established for preparation and participation.
Agenda should be formal enough to cover all important points, but informal enough
to encourage the free flow of ideas.
A facilitator controls the meeting.
A definition mechanism (blackboard, flip charts, etc.) is used.
Flow of event Outline the sequence of events occurs
Requirement gathering meeting ( initial meeting)
During meeting
Follow the meeting.
A meeting Place, time and date and a facilitator is chosen
In initial meeting, distribute Product request (defined by stakeholders) to all attendee.
Based on product request, each attendee is asked to make
List of objects (Internal or external system objects)
List of services( Processes or functions)
List of constraints (cost, size, business rules) and performance criteria (speed,
accuracy) are developed.
Collect lists from everyone and combined.
Combined list eliminates redundant entries, add new ideas, but does not delete anything.
Objective is to develop a consensus list in each topic area (objects, services, constraints and
performance).
Based on lists, team is divided into smaller sub-teams: each works to develop mini-
specification for one or more entries on each of the lists.
Each sub-team then presents its mini-specification to all attendees for discussion. Addition,
deletion and further elaboration are made.
Now each team makes a list of validation criteria for the product and present to team.
Finally, one or more participants is assigned the task of writing a complete draft specification
Quality Function Deployment
It is a technique that translate the needs of the customer into technical requirement for
software.
Concentrates on maximizing customer satisfaction.
QFD emphasizes what is valuable to the customer and then deploys these values throughout
the engineering process.
Three types of requirement:
1. Normal Requirements reflect objectives and goals stated for product. If requirement are
present in final products, customer is satisfied.
2. Expected Requirements customer does not explicitly state them. Customer assumes it is
implicitly available with the system.
3. Exciting Requirements- Features that go beyond the customers expectation.
4. During meeting with customer
1. Function deployment determines the value of each function required of the system.
2. Information deployment identifies data objects and events and also tied with
functions.
3. Task deployment examines the behavior of the system.
4. Value analysis determines the priority of requirements during these 3 deployments.
5. Customer Voice Table:
1. Data for the requirements gathering.
2. Reviewed with customer.
User Scenario
It is difficult to move into more software engineering activities until s/w team understands
how these functions and features will be used by different end-users.
Developers and users create a set of usage threads for the system to be constructed
A use-case scenario is a story about how someone or something external to the software
(known as an actor) interacts with the system.
Describe how the system will be used
Each scenario is described from the point-of-view of an actora person or device that
interacts with the software in some way
Elicitation Work Products
Elicitation work product will vary depending upon the size of the system or product to be
built.
Statement of need and feasibility.
Statement of scope.
List of participants in requirements elicitation.
Description of the systems technical environment.
List of requirements and associated domain constraints.
List of usage scenarios.
Any prototypes developed to refine requirements.
Reviewed by the participants of requirement Elicitation.
Developing Use Cases
A Use Case depicts the software or system from the end users point of view.
Step One Define the set of actors that will be involved in the story
Actors are people, devices, or other systems that use the system or product within the
context of the function and behavior that is to be described
Actors are anything that communicate with the system or product and that are
external to the system itself
Step Two Develop use cases, where each one answers a set of questions
Who is the primary actor(s), the secondary actor(s)?
What are the actors goals?
What preconditions should exist before the scenario begins?
What main tasks or functions are performed by the actor?
What exceptions might be considered as the scenario is described?
What variations in the actors interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
Use case Relationships
Association:
The association relationship is the interface between an actor and a use case.
Generalization
The generalization relationship is a link between use cases.
shows that one use case is simply a special kind of another
A child can be substituted for its parent whenever necessary
<<include>>
They include relationship allows one use case to include the functionality of another.
The arrow points from the use case that includes the additional functionality to the
use case being included.
They include relationship is represented by a dashed line with an arrowhead.
<<extend>>
The extend relationship combines the functionality of one use case with the
functionality of another, if certain conditions exist.
Extending use case typically defines optional behavior that is not necessarily
meaningful by itself.
The extend relationship is represented by a dashed line with an arrowhead.
The arrow points from the use case that provides the additional functionality to the
use case that accepts the functionality.
Building the Analysis Model
Provides a description of the required informational, functional and behavioral domains for a
computer based system.
The model changes dynamically as S/W engineers learn more about the system and the
stakeholders understand more about what they really require.
As the model evolves, certain elements will become relatively stable, providing a solid
foundation for the design task.
Information domain encompasses that the data flow into the system, out of the system and
data stored.
Functions provide direct benefit to end-users and also provide internal support for those
features that are user visible.
Behavior driven by its interaction with the external environment.
Elements of the Analysis Model
Structured analysis
Considers data and the processes that transform the data as separate entities
Data is modeled in terms of only attributes and relationships (but no operations)
Processes are modeled to show the 1) input data, 2) the transformation that occurs on
that data, and 3) the resulting output data
Object-oriented analysis
Focuses on the definition of classes and the manner in which they collaborate with
one another to fulfill customer requirements
Scenario-based elements
Describe the system from the user's point of view using scenarios that are depicted in
use cases and activity diagrams
Class-based elements
Identify the domain classes for the objects manipulated by the actors, the attributes of
these classes, and how they interact with one another; they utilize class diagrams to
do this
Behavioral elements
Use state diagrams to represent the state of the system, the events that cause the
system to change state, and the actions that are taken as a result of a particular event;
can also be applied to each class in the system
Flow-oriented elements
Use data flow diagrams to show the input data that comes into a system, what
functions are applied to that data to do transformations, and what resulting output
data are produced
Object-oriented Analysis
Structured Analysis
Scenario-based Flow-oriented
Use case text Data structure diagrams
Use case diagrams Data flow diagrams
Class-based Behavioral
Class diagrams State diagrams
Analysis packages Sequence diagrams
Analysis Patterns
Suggest solutions within the application domain that can be reused when modeling many
applications.
Uses:
Speed up the development of abstract analysis models
Facilitate the transformation of the analysis model into a design model.
Integrated into the analysis model by reference to the pattern name.
Negotiating Requirements
Intention is to develop a project plan that meets stakeholder needs while at the same time
reflecting the real world constraints that have been placed on the software team.
Win Win result
Activities
Identification of the system or subsystems key stakeholders.
Determination of the stakeholders win conditions.
Negotiation of the stakeholders win condition to reconcile them into a set of win-win
condition for all concerned.
The Art of Negotiation
Recognize that it is not competition
Map out a strategy
Listen actively
Focus on the other partys interests
Dont let it get personal
Be creative
Be ready to commit
Specification Task
A specification is the final work product produced by the requirements engineer
It is normally in the form of a software requirements specification
It serves as the foundation for subsequent software engineering activities
It describes the function and performance of a computer-based system and the constraints that
will govern its development
It formalizes the informational, functional, and behavioral requirements of the proposed
software in both a graphical and textual format
Specification Task
A specification is the final work product produced by the requirements engineer
It is normally in the form of a software requirements specification
It serves as the foundation for subsequent software engineering activities
It describes the function and performance of a computer-based system and the constraints that
will govern its development
It formalizes the informational, functional, and behavioral requirements of the proposed
software in both a graphical and textual format
Validating Requirements
During validation, the work products produced as a result of requirements engineering are
assessed for quality
The specification is examined to ensure that
all software requirements have been stated unambiguously
inconsistencies, omissions, and errors have been detected and corrected
the work products conform to the standards established for the process, the project,
and the product
The formal technical review serves as the primary requirements validation mechanism
Members include software engineers, customers, users, and other stakeholders
Questions to ask when Validating Requirements
Is each requirement consistent with the overall objective for the system/product?
Have all requirements been specified at the proper level of abstraction? That is, do some
requirements provide a level of technical detail that is inappropriate at this stage?
Is the requirement really necessary or does it represent an add-on feature that may not be
essential to the objective of the system?
Is each requirement bounded and unambiguous?
Does each requirement have attribution? That is, is a source (generally, a specific individual)
noted for each requirement?
Do any requirements conflict with other requirements?
Is each requirement achievable in the technical environment that will house the system or
product?
Is each requirement testable, once implemented?
Approaches: Demonstration, actual test, analysis, or inspection
Does the requirements model properly reflect the information, function, and behavior of the
system to be built?
Has the requirements model been partitioned in a way that exposes progressively more
detailed information about the system?
