UNIT II

Software
Requirement
Engineering and
Analysis

Prof. Bhagyashri F. More, Computer Department, MESCOE

 Contents
• Modeling: Requirements Engineering, Establishing the
Groundwork, Identifying Stakeholders, Recognizing Multiple
Viewpoints, working toward Collaboration, Asking the First
Questions, Eliciting Requirements, Collaborative Requirements
Gathering, Usage Scenarios, Elicitation Work Products, Developing
Use Cases, Building the Requirements Model, Elements of the
Requirements Model, Negotiating Requirements, Validating
Requirements.
• Suggested Free Open Source tools: StarUML, Modelio,
SmartDraw.
 Requirements Engineering
• Requirements engineering (RE) refers to the process of
defining, documenting, and maintaining requirements in the
engineering design process.
• Requirement engineering provides the appropriate mechanism to
understand what the customer desires, analyzing the need, and
assessing feasibility, negotiating a reasonable solution, specifying
the solution clearly, validating the specifications and managing the
requirements as they are transformed into a working system.
• Thus, requirement engineering is the disciplined application of
proven principles, methods, tools, and notation to describe a
proposed system's intended behavior and its associated
constraints.
Requirement Engineering
Process
 Requirement Engineering
Process
• It is a four-step process, which includes -
1.Feasibility Study (Inception)
2.Requirement Elicitation and Analysis
3.Software Requirement Specification
4.Software Requirement Validation
5.Software Requirement Management
 1. Feasibility Study
• The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.
• Types of Feasibility:
1.Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements within
the time and budget.
2.Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.
3.Economic Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization.
 2. Requirement Elicitation and
Analysis
• This is also known as the gathering of requirements.
Here, requirements are identified with the help of customers
and existing systems processes, if available.
• Analysis of requirements starts with requirement elicitation.
The requirements are analyzed to identify inconsistencies,
defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.
• Problems of Elicitation and Analysis
Getting all, and only, the right people involved.
Stakeholders often don't know what they want
Stakeholders express requirements in their terms.
Stakeholders may have conflicting requirements.
Requirement change during the analysis process.
Organizational and political factors may influence system
requirements.
 3. Software Requirement
Specification
• Software requirement specification is a kind of document
which is created by a software analyst after the
requirements collected from the various sources - the
requirement received by the customer written in ordinary
language. It is the job of the analyst to write the requirement
in technical language so that they can be understood and
beneficial by the development team.
• The models used at this stage include ER diagrams, data
flow diagrams (DFDs), function decomposition diagrams
(FDDs), data dictionaries, etc.
 3. Software Requirement
Specification
• Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows the flow of data through a system.
The system may be a company, an organization, a set of procedures, a
computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.
• Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements stage,
the data dictionary should at least define customer data items, to ensure that
the customer and developers use the same definition and terminologies.
• Entity-Relationship Diagrams: Another tool for requirement specification
is the entity-relationship diagram, often called an "E-R diagram." It is a
detailed logical representation of the data for the organization and uses three
main constructs i.e. data entities, relationships, and their associated
attributes.
 4. Software Requirement
Validation
• After requirement specifications developed, the requirements discussed in this
document are validated. The user might demand illegal, impossible solution or
experts may misinterpret the needs. Requirements can be the check against the
following conditions -
• If they can practically implement
• If they are correct and as per the functionality and specially of software
• If there are any ambiguities
• If they are full
• If they can describe
Requirements Validation Techniques
• Requirements reviews/inspections: systematic manual analysis of the
requirements.
• Prototyping: Using an executable model of the system to check requirements.
• Test-case generation: Developing tests for requirements to check testability.
• Automated consistency analysis: checking for the consistency of structured
requirements descriptions.
Validation: Are we building the right system?
Verification: Are we building the system right?
 5. Software Requirement
Management
• Requirement management is the process of managing changing
requirements during the requirements engineering process and
system development.
• New requirements emerge during the process as business needs
a change, and a better understanding of the system is
developed.
• The priority of requirements from different viewpoints changes
during development process.
• The business and technical environment of the system changes
during the development.
 Prerequisite of Software
requirements
• Collection of software requirements is the basis of the entire
software development project. Hence they should be clear, correct,
and well-defined.
• A complete Software Requirement Specifications should be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source
 Prerequisite of Software
requirements
• The steps required to establish the groundwork for an
understanding of software requirements—to get the project started
in a way that will keep it moving forward toward a successful
solution.
1. Identifying Stakeholders
2. Recognizing Multiple Viewpoints
3. Working toward Collaboration
4. Asking the First Questions
5. Nonfunctional Requirements
6. Traceability
1.Identifying Stakeholders
• Identify the usual suspects: business operations managers, product
managers, marketing people, internal and external customers, end
users, consultants, product engineers, software engineers, support
and maintenance engineers, and others.
• Each stakeholder has a different view of the system, achieves
different benefi ts when the system is successfully developed, and
is open to different risks if the development effort should fail.
• At inception, you should create a list of people who will contribute
input as requirements are elicited.
 Recognizing Multiple Viewpoints
• As information from multiple viewpoints is collected, emerging
requirements may be inconsistent or may conflict with one another.
• You should categorize all stakeholder information (including
inconsistent and conflicting requirements) in a way that will allow
decision makers to choose an internally consistent set of
requirements for the system.
• The goal of effective requirements engineering is to
eliminate or at least reduce these problems.
 Working toward Collaboration
l
The job of a requirements engineer is to identify areas of
commonality (i.e.,requirements on which all stakeholders agree) and
areas of confl ict or inconsistency (i.e., requirements that are desired
by one stakeholder but confl ict with the needs of another
stakeholder).
l
It is, of course, the latter category that presents a challenge.
l
Collaboration does not necessarily mean that requirements are defi
ned by committee. In many cases, stakeholders collaborate by
providing their view of requirements, but a strong “project champion”
(e.g., a business manager or a senior technologist) may make the fi
nal decision about which requirements make the cut.
 4. Asking the First Questions
The first set of context-free questions focuses on the customer and other
stakeholders, the overall project goals and benefits. For example, you
might ask:
l
Who is behind the request for this work?
l
Who will use the solution?
l
What will be the economic benefi t of a successful solution?
l
Is there another source for the solution that you need?

The questions identify the measurable benefit of a successful

implementation and possible alternatives to custom software
development.
The next set of questions enables you to gain a better understanding of
the problem and allows the customer to voice his or her perceptions
about a solution
 5. Nonfunctional Requirements
l
A nonfunctional requirement (NFR) can be described as a quality
attribute, a performance attribute, a security attribute, or a general
constraint on a system.
l
Quality function deployment attempts to translate unspoken customer
needs or goals into system requirements. Nonfunctional requirements
are often listed separately in a software requirements specification.

1. a set of software engineering guidelines is established for the system

to be built.
2. the team prioritizes each nonfunctional requirement by creating a
homogeneous set of nonfunctional requirements using a set of decision
rules that establish which guidelines to implement and which to reject.
 Traceability
l
It is Refers to documented links between software engineering work
products (e.g., requirements and test cases).
l
A traceability matrix allows a requirements engineer to represent the
relationship between requirements and other software engineering
work products.
l
The traceability matrices can support a variety of engineering
development activities. They can provide continuity for developers as a
project moves from one project phase to another, regardless of the
process model being used.
 Eliciting Requirements
l
Requirements elicitation (also called requirements gathering )
combines elements of problem solving, elaboration, negotiation, and
specifi cation.
l
In order to encourage a collaborative, team-oriented approach to
requirements gathering, stakeholders work together to identify the
problem, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements.
1. Collaborative Requirements Gathering
2. Usage Scenarios
3. Elicitation Work Products
 Collaborative Requirements
Gathering
l
Meetings (either real or virtual) are conducted and attended by both
soft-ware engineers and other stakeholders.
l
Rules for preparation and participation are established.
l
An agenda is suggested that is formal enough to cover all important
l
points but informal enough to encourage the free fl ow of ideas.
l
A “facilitator” (can be a customer, a developer, or an outsider) controls
the meeting.
l
A “defi nition mechanism” (can be work sheets, fl ip charts, or wall
stickers or an electronic bulletin board, chat room, or virtual forum) is
used.
l
The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a
preliminary set of solution requirements.
 Usage Scenarios
l
The developers and users can create a set of scenarios that identify a
thread of usage for the system to be constructed.
l
The scenarios, often called use cases provide a description of how the
system will be used.
 Elicitation Work Products
l
The work products produced as a consequence of requirements
elicitation will vary depending on the size of the system or product to
be built.
(1) a statement of need and feasibility,
(2) a bounded statement of scope for the system or product
(3) a list of customers, users, and other stakeholders who participated in
requirements elicitation
(4) a description of the system’s technical environment
(5) a list of requirements (preferably organized by function) and the
domain constraints that applies to each
(6) a set of usage scenarios that provide insight into the use of the
system or product under different operating conditions
(7) any prototypes developed to better defi ne requirements.
l
Each of these work products is reviewed by all people who have
participated in requirements elicitation.
 Developing Use Case
l
Use Case
l
A use case tells a stylized story about how an end user (playing one of
a number of possible roles) interacts with the system under a specifi c
set of circumstances.
l
The story may be narrative text, an outline of tasks or interactions, a
template-based description, or a diagrammatic representation.
l
Regardless of its form, a use case depicts the software or system from
the end user’s point of view.
 Developing Use Case
l
The first step in writing a use case is to define the set of “actors” that
will be involved in the story.
l
Actors are the different people (or devices) that use the system or
product within the context of the function and behavior that is to be
described.
l
Actors represent the roles that people (or devices) play as the system
operates.
l
Defined somewhat more formally, an actor is anything that
communicates with the system or product and that is external to the
system itself.
l
Every actor has one or more goals when using the system.
 Use Case Components
l
Actor
l
Someone interacts with use case (system function).
l
Named by noun.
l
Actor plays a role in the business
l
Similar to the concept of user, but a user can play different roles
l
For example:
l
A prof. can be instructor and also researcher plays 2 roles with two
systems
l
Actor triggers use case(s).
l
Actor has a responsibility toward the system (inputs), and Actor has
expectations from the system (outputs).
 Use Case Components
l
Use Case
l
System function (process - automated or manual)
l
Named by verb + Noun (or Noun Phrase).
l
i.e. Do something
l
Each Actor must be linked to a use case, while some use cases may
not be linked to actors.
 Use Case Components
l
Communication Link
l
The participation of an actor in a use case is shown by connecting an
actor to a use case by a solid link.
l
Actors may be connected to use cases by associations, indicating that
the actor and the use case communicate with one another using
messages.
 Use Case Components
l
Boundary of system
l
The system boundary is potentially the entire
system as defined in the requirements
document.
l
For large and complex systems, each module
may be the system boundary.
l
For example, for an ERP system for an
organization, each of the modules such as
personnel, payroll, accounting, etc.
l
can form a system boundary for use cases
specific to each of these business functions.
l
The entire system can span all of these
modules depicting the overall system boundary
 Use Case Relationship
l
Extends
l
Indicates that an "Invalid Password" use case may include (subject to
specified in the extension) the behavior specified by base use case
"Login Account".
l
Depict with a directed arrow having a dotted line. The tip of arrowhead
points to the base use case and the child use case is connected at the
base of the arrow.
l
The stereotype "<<extends>>" identifies as an extend relationship
 Use Case Relationship
l
Include
l
When a use case is depicted as using the functionality of another use case, the
relationship between the use cases is named as include or uses relationship.
l
A use case includes the functionality described in another use case as a part of
its business process flow.
l
A uses relationship from base use case to child use case indicates that an
instance of the base use case will include the behavior as specified in the child
use case.
l
An include relationship is depicted with a directed arrow having a dotted line.
The tip of arrowhead points to the child use case and the parent use case
connected at the base of the arrow.
l
The stereotype "<<include>>" identifies the relationship as an include
relationship.
 Use Case Relationship
l
Generalization
l
A generalization relationship is a parent-child relationship between use
cases.
l
The child use case is an enhancement of the parent use case.
l
Generalization is shown as a directed arrow with a triangle arrowhead.
l
The child use case is connected at the base of the arrow. The tip of the
arrow is connected to the parent use case.
 Online shopping system

View product
<<extend>> Discount

order <<include>>

User Login
<<include>>

payment
<<include>>

Cancel order
registered Non
registered
Admin
Confirm/Cancel order

status

Bank report
 Building the Requirements
Model
l
The intent of the analysis model is to provide a description of the
required informational, functional, and behavioral domains for a
computer-based system.
l
The model changes dynamically as you learn more about the system
to be built, and other stakeholders understand more about what they
really require.
 Elements of the Analysis Model
l
There are many different ways to look at the requirements for a
computer-based system.
l
Different modes of representation force you to consider requirements
from different viewpoints—an approach that has a higher probability of
uncovering omissions, inconsistencies, and ambiguity.
l
1. Scenario-based elements.
l
2. Class-based elements.
l
3. Behavioral elements
UML activity diagrams for eliciting requirements
 l
Scenario-based elements
l
The system is described from the user’s point of view using a scenario-
based approach.
l
For example, basic use cases and their corresponding use case
diagrams evolve into more elaborate template-based use cases.
l
Scenario-based elements of the requirements model are often the fi rst
part of the model that is developed.
l
As such, they serve as input for the creation of other modeling
elements.
l
Activity Diagram
l
Scenario-based elements
 Activity Diagram
l
The activity diagram is used to demonstrate the flow of control within
the system rather than the implementation. It models the concurrent
and sequential activities.
l
The activity diagram helps in envisioning the workflow from one activity
to another.
l
It put emphasis on the condition of flow and the order in which it
occurs.
l
The flow can be sequential, branched, or concurrent, and to deal with
such kinds of flows, the activity diagram has come up with a fork, join,
etc.
l
It is also termed as an object-oriented flowchart. It encompasses
activities composed of a set of actions or operations that are applied to
model the behavioral diagram.
 Components of an Activity
Diagram
l
Activities:
l
The categorization of behavior into one or more actions is termed as
an activity. In other words, it can be said that an activity is a network of
nodes that are connected by edges. The edges depict the flow of
execution. It may contain action nodes, control nodes, or object nodes.
 Components of an Activity
Diagram
l
Activity partition /swimlane
l
The swimlane is used to cluster all the related activities in one column
or one row. It can be either vertical or horizontal. It used to add
modularity to the activity diagram. It is not necessary to incorporate
swimlane in the activity diagram. But it is used to add more
transparency to the activity diagram.
 Components of an Activity
Diagram
l
Forks
l
Forks and join nodes generate the concurrent flow inside the activity. A
fork node consists of one inward edge and several outward edges. It is
the same as that of various decision parameters. Whenever a data is
received at an inward edge, it gets copied and split crossways various
outward edges. It split a single inward flow into multiple parallel flows.
 Components of an Activity
Diagram
l
Join Nodes
l
Join nodes are the opposite of fork nodes. A Logical AND operation is
performed on all of the inward edges as it synchronizes the flow of
input across one single output (outward) edge.
 Notation of an Activity diagram
l
Activity diagram constitutes following
notations:
l
Initial State: It depicts the initial stage
or beginning of the set of actions.
l
Final State: It is the stage where all
the control flows and object flows end.
l
Decision Box: It makes sure that the
control flow or object flow will follow
only one path.
l
Action Box: It represents the set of
actions that are to be performed.
 Why use Activity Diagram?
l
An event is created as an activity diagram encompassing a group of
nodes associated with edges.
l
To model the behavior of activities, they can be attached to any
modeling element. It can model use cases, classes, interfaces,
components, and collaborations.
l
It mainly models processes and workflows. It envisions the dynamic
behavior of the system as well as constructs a runnable system that
incorporates forward and reverse engineering.
l
It does not include the message part, which means message flow is
not represented in an activity diagram.
l
It is the same as that of a flowchart but not exactly a flowchart itself. It
is used to depict the flow between several activities.
 Components of an Activity
Diagram
l
Following are the rules that are to be followed for drawing an activity
diagram:
l
1. A meaningful name should be given to each and every activity.
l
2. Identify all of the constraints.
l
3. Acknowledge the activity associations.
 When to use an Activity
Diagram?
l
An activity diagram can be used to portray business processes and
workflows. Also, it used for modeling business as well as the software.
An activity diagram is utilized for the followings:
l
To graphically model the workflow in an easier and understandable
way.
l
To model the execution flow among several activities.
l
To model comprehensive information of a function or an algorithm
employed within the system.
l
To model the business process and its workflow.
l
To envision the dynamic aspect of a system.
l
To generate the top-level flowcharts for representing the workflow of an
application.
l
To represent a high-level view of a distributed or an object-oriented
system.
Examples
 Class Diagram
• The class diagram depicts a static view of an application. It
represents the types of objects residing in the system and
the relationships between them. A class consists of its
objects, and also it may inherit from other classes. A class
diagram is used to visualize, describe, document various
different aspects of the system, and also construct
executable software code.
• It shows the attributes, classes, functions, and relationships
to give an overview of the software system. It constitutes
class names, attributes, and functions in a separate
compartment that helps in software development. Since it is
a collection of classes, interfaces, associations,
collaborations, and constraints, it is termed as a structural
diagram.
 Purpose of Class Diagrams
• The main purpose of class diagrams is to build a static view
of an application. It is the only diagram that is widely used
for construction, and it can be mapped with object-oriented
languages. It is one of the most popular UML diagrams.
Following are the purpose of class diagrams given below:
1.It analyses and designs a static view of an application.
2.It describes the major responsibilities of a system.
3.It is a base for component and deployment diagrams.
4.It incorporates forward and reverse engineering.
 Benefits of Class Diagrams
• It can represent the object model for complex systems.
• It reduces the maintenance time by providing an overview of
how an application is structured before coding.
• It provides a general schematic of an application for better
understanding.
• It represents a detailed chart by highlighting the desired
code, which is to be programmed.
• It is helpful for the stakeholders and the developers.
 Vital components of a Class
Diagram
• The class diagram is made up of three sections:
• Upper Section: The upper section encompasses the name of the class. A
class is a representation of similar objects that shares the same
relationships, attributes, operations, and semantics. Some of the following
rules that should be taken into account while representing a class are given
below:
– Capitalize the initial letter of the class name.
– Place the class name in the center of the upper section.
– A class name must be written in bold format.
– The name of the abstract class should be written in italics format.
• Middle Section: The middle section constitutes the attributes, which
describe the quality of the class. The attributes have the following
characteristics:
– The attributes are written along with its visibility factors, which are public
(+), private (-), protected (#), and package (~).
– The accessibility of an attribute class is illustrated by the visibility factors.
– A meaningful name should be assigned to the attribute, which will explain
its usage inside the class.
 Continue…
• Lower Section: The lower section contain methods or
operations. The methods are represented in the form of a
list, where each method is written in a single line. It
demonstrates how a class interacts with data.

+ denotes public attributes or operations

- denotes private attributes or operations
# denotes protected attributes or operations
~ denotes package attributes or operations
 Relationships
• In UML, relationships are of three types:
• Dependency: A dependency is a semantic relationship
between two or more classes where a change in one class
cause changes in another class. It forms a weaker
relationship.
In the following example, Student_Name is dependent on the
Student_Id.
 Relationships
Generalization: A generalization is a relationship between a
parent class (superclass) and a child class (subclass). In this,
the child class is inherited from the parent class.
• For example, The Current Account, Saving Account, and
Credit Account are the generalized form of Bank Account.
 Relationships
Association: It describes a static or physical connection
between two or more objects. It depicts how many objects are
there in the relationship.
For example, a department is associated with the college
 Relationships
Multiplicity: It defines a specific range of allowable instances
of attributes. In case if a range is not specified, one is
considered as a default multiplicity.
For example, multiple patients are admitted to one hospital.

1) Exactly one - 1
2) Zero or one - 0..1
3) Many - 0..* or *
4) One or more - 1..*
5) Exact Number - e.g. 3..4 or 6
6) Or a complex relationship - e.g. 0..1, 3..4, 6.*
7)would mean any number of
8)objects other than 2 or 5
 Relationships
Aggregation: An aggregation is a subset of association,
which represents has a relationship. It is more specific then
association. It defines a part-whole or part-of relationship. In
this kind of relationship, the child class can exist
independently of its parent class.
The company encompasses a number of employees, and even
if one employee resigns, the company still exists.
 Relationships
Composition: The composition is a subset of aggregation. It
portrays the dependency between the parent and its child,
which means if one part is deleted, then the other part also
gets discarded. It represents a whole-part relationship.
A contact book consists of multiple contacts, and if you delete
the contact book, all the contacts will be lost.
 How to draw a Class
Diagram?
• The class diagram is used most widely to construct software applications. It not
only represents a static view of the system but also all the major aspects of an
application. A collection of class diagrams as a whole represents a system.
• Some key points that are needed to keep in mind while drawing a class diagram
are given below:
1. To describe a complete aspect of the system, it is suggested to give a meaningful
name to the class diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of
the unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the
aspects of a diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct
before producing its final version.
Class Diagram Example
• A class diagram describing the sales order system is given below.
ATM System
 Behavioral elements
l
The behavior of a computer-based system can have a profound effect
on the design that is chosen and the implementation approach that
Therefore, the requirements model must provide modeling elements
that depict behavior.
l
The state diagram is one method for representing the behavior of a
system by depicting its states and the events that cause the system to
change state. A state is any observable mode of behavior. In addition,
the state diagram indicates what actions (e.g., process activation) are
taken as a consequence of a particular event.
 State Diagram
l
A state diagram is used to represent the condition of the system or part
of the system at finite instances of time. It’s a behavioral diagram and it
represents the behavior using finite state transitions.
l
State diagrams are also referred to as State machines and State-chart
Diagrams. These terms are often used interchangeably. So simply, a
state diagram is used to model the dynamic behavior of a class in
response to time and changing external stimuli.
l
We can say that each and every class has a state but we don’t model
every class using State diagrams. We prefer to model the states with
three or more states.
 Uses of statechart diagram
l
We use it to state the events responsible for change in state (we do not
show what processes cause those events).
l
We use it to model the dynamic behavior of the system .
l
To understand the reaction of objects/classes to internal or external
stimuli.
l
Difference between state diagram and flowchart –
l
The basic purpose of a state diagram is to portray various changes in
state of the class and not the processes or commands causing the
changes. However, a flowchart on the other hand portrays the
processes or commands that on execution change the state of class or
an object of the class.
 Basic components of a
statechart diagram
l
Initial state – We use a black filled circle represent the initial state of a
System or a class.

l
Transition – We use a solid arrow to represent the transition or change
of control from one state to another. The arrow is labelled with the
event which causes the change in state.
l
State – We use a rounded rectangle to represent a state. A state
represents the conditions or circumstances of an object of a class at
an instant of time.
l
Fork – We use a rounded solid rectangular bar to represent a Fork
notation with incoming arrow from the parent state and outgoing
arrows towards the newly created states. We use the fork notation to
represent a state splitting into two or more concurrent states.
l
Join – We use a rounded solid rectangular bar to represent a Join
notation with incoming arrows from the joining states and outgoing
arrow towards the common goal state. We use the join notation when
two or more states concurrently converge into one on the occurrence
of an event or events.
l
Self transition – We use a solid arrow pointing back to the state itself to
represent a self transition. There might be scenarios when the state of
the object does not change upon the occurrence of an event. We use
self transitions to represent such cases.
l
Final state – We use a filled circle within a circle notation to represent
the final state in a state machine diagram.
Basic components of a
statechart diagram
 l
Steps to draw a state diagram
l
Identify the initial state and the final terminating states.
l
Identify the possible states in which the object can exist (boundary
values corresponding to different attributes guide us in identifying
different states).
l
Label the events which trigger these transitions.
Example – state diagram for an
online order
 Negotiating Requirements
l
The best negotiations strive for a “win-win” result. 21 That is,
stakeholders win by getting the system or product that satisfi es the
majority of their needs and you (as a member of the software team)
win by working to realistic and achievable budgets and deadlines.
l
Rather than a single customer communication activity, the following
activities are defi ned:
l
1. Identifi cation of the system or subsystem’s key stakeholders.
l
2. Determination of the stakeholders’ “win conditions.”
l
3. Negotiation of the stakeholders’ win conditions to reconcile them into
a set of win-win conditions for all concerned (including the software
team).
 Negotiating Requirements
l
In handshaking, the software team proposes solutions to requirements,
describes their impact, and communicates their intentions to customer
representatives.
l
The customer representatives review the proposed solutions, focusing
on missing features and seeking clarifi cation of novel requirements.
Requirements are determined to be good enough if the customers
accept the proposed solution.
l
Handshaking allows detailed requirements to be delegated to software
teams. The teams need to elicit requirements from customers (e.g.,
product users and domain experts), thereby improving product
acceptance. Handshaking tends to improve identifi cation, analysis,
and selection of variants and promotes win-win negotiation.
 Validating Requirements
l
As each element of the requirements model is created, it is examined
for inconsistency, omissions, and ambiguity. The requirements
represented by the model are prioritized by stakeholders and grouped
within requirements packages that will be implemented as software
increments. A review of the requirements model addresses the
following questions:
l
1. Is each requirement consistent with the overall objectives for the
system or product?
l
2. Have all requirements been specifi ed at the proper level of
abstraction? That is, do some requirements provide a level of technical
detail that is inappropriate at this stage?
l
3. Is the requirement really necessary or does it represent an add-on
feature that may not be essential to the objective of the system?
 Validating Requirements
5. Is each requirement bounded and unambiguous?
6. Does each requirement have attribution? That is, is a source
(generally, a specifi c individual) noted for each requirement?
7. Do any requirements confl ict with other requirements?
8. Is each requirement achievable in the technical environment that will
house the system or product?
8. Is each requirement testable, once implemented?
9.Does the requirements model properly refl ect the information,
function, and behavior of the system to be built?

l
These and other questions should be asked and answered to ensure
that the requirements model is an accurate refl ection of stakeholder
needs and that it provides a solid foundation for design.