Chapter: Requirement

Engineering
Requirements Engineering

• Requirement: A function, constraint or other property that

the system must provide to fill the needs of the system’s
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
Requirements Engineering
• 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 abbreviated, 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 don’t 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.
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.
Egs: ATM stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators
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.
Inception
• During inception, the requirements engineer asks a set of questions to
establish…
• A basic understanding of the problem
• The people who want a solution
• The nature of the solution that is desired
• The effectiveness of preliminary communication and collaboration between the
customer and the developer
• Through these questions, the requirements engineer needs to…
• Identify the stakeholders
• Recognize multiple viewpoints
• Work toward collaboration
• Break the ice and initiate the communication

10
 The First Set of Questions
These questions focus on the customer, other
stakeholders, the overall goals, and the benefits

• 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?

11
 The Next Set of Questions
These questions enable the requirements engineer to
gain a better understanding of the problem and allow
the customer to voice his or her perceptions about a
solution

• How would you characterize "good" output that would be generated by

a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the
solution will be used?
• Will special performance issues or constraints affect the way the solution
is approached?

12
 The Final Set of Questions
These questions focus on the effectiveness of
the communication activity itself

• Are you the right person to answer these questions? Are your answers
"official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

13
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
 Why Requirement elicitation is difficult?

• Problems of scope:
• The boundary of the system is ill-defined.
• Customers/users specify unnecessary technical detail that may confuse rather than clarify objectives.
• Problem of understanding:
• Customers are not completely sure of what is needed.
• Customers have a poor understanding of the capabilities and limitations of the computing environment.
• Customers don’t have a full understanding of their problem domain.
• Customers have trouble communicating needs to the system engineer.
• Customers omit detail that is believed to be obvious.
• Customers specify requirements that conflict with other requirements.
• Customers specify requirements that are ambiguous or not able to test.
• Problems of volatility:
• Requirement change over time.
• Elicitation may be accomplished through two activities
• Collaborative requirements gathering
• Quality function deployment
 Collaborative Requirement Gathering
• 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.
• During the meeting:
• The problem is identified.
• Elements of the solution are proposed.
• Different approaches are negotiated.
• A preliminary set of solution requirements are obtained.
• The atmosphere is collaborative and non-threatening.
• Flow of event – Outline the sequence of events occurs
• Requirement gathering meeting ( initial meeting)
• During meeting
• Follow the meeting.
 Collaborative requirement gathering (contd.)
• In initial meeting, distribute “Product request” (defined by stakeholder) 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.
 Collaborative requirement gathering (Contd.)

• Each sub-team the 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 – These requirements are the objectives and goals stated for
a product or system during meetings with the customer
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 customer’s expectation.
During meeting with customer –
Function deployment determines the “value” of each function required of the system.
Information deployment identifies data objects and events and also tied with functions.
Task deployment examines the behavior of the system.
Value analysis determines the priority of requirements during these 3 deployments.
Elaboration
• During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand and
refine it
• Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
• It is an analysis modeling task
• Use cases are developed
• Domain classes are identified along with their attributes and relationships
• State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional,
informational, and behavioral domains of the problem
21
Developing Use Cases

• 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

23
Use Case Example for Operating the SafeHome Control
Panel
 Questions Commonly Answered by a Use Case
• Who is the primary actor(s), the secondary actor(s)?
• What are the actor’s 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 actor’s 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?

25
 Initial
Monitoring
Use-Case
Diagram
for the
SafeHome
System
 Elements of the Analysis Model
• 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

29
Negotiation
• During negotiation, the software engineer reconciles the conflicts
between what the customer wants and what can be achieved given
limited business resources
• Requirements are ranked (i.e., prioritized) by the customers, users, and
other stakeholders
• Risks associated with each requirement are identified and analyzed
• Rough guesses of development effort are made and used to assess the
impact of each requirement on project cost and delivery time
• Using an iterative approach, requirements are eliminated, combined
and/or modified so that each party achieves some measure of
satisfaction
30
The Art of Negotiation

• Recognize that it is not competition

• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit

31
Specification
• 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
32
Typical Contents of a Software Requirements
Specification
• Requirements
• Required states and modes
• Software requirements grouped by capabilities (i.e., functions, objects)
• Software external interface requirements
• Software internal interface requirements
• Software internal data requirements
• Other software requirements (safety, security, privacy, environment, hardware,
software, communications, quality, personnel, training, logistics, etc.)
• Design and implementation constraints
• Qualification provisions to ensure each requirement has been met
• Demonstration, test, analysis, inspection, etc.
• Requirements traceability
• Trace back to the system or subsystem where each requirement applies

33
 Software Requirements Specification
• It contains a complete information description, a detailed functional description, a representation of
system behavior, an indication of performance requirements and design constraints, appropriate
validation criteria, and other information pertinent to requirements.
Format of SRS:
Introduction of the software requirements specification states the goals and objectives of the software,
describing it in the context of the computer-based system.
Information content, flow, and structure are documented. Hardware, software, and human interfaces are
described for external system elements and internal software functions.
Functional Description A processing narrative is provided for each function, design constraints are
stated and justified & performance characteristics are stated

Behavioral Description operation of the software as a consequence of external events and internally
generated control characteristics.
Validation Criteria is probably the most important and, ironically, the most often
neglected section of the Software Requirements Specification (SRS). Testing or validating
each user-scenario.
Validation
• 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

35
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?

36
Questions to ask when Validating Requirements
(continued)
• 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?

37
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.
Software Prototype
• Prototype constructed for customer and developer assessment.
• In some circumstances construction of prototype is require in beginning of
analysis. (To derive requirement effectively)
Selecting Prototype Approach
1.Close ended (Throwaway Approach)
2.Open ended (Evolutionary Approach)
Close Ended – It serves as a rough demonstration of requirement. It is then
discarded, and the software engineered using a different paradigm.
Open Ended - uses the prototype as the first part of an analysis activity that
will be continued into design and construction. The prototype of the
software is the first evolution of the finished system.
Approaches to prototyping

Evolutionary Delivered
prototyping system
Outline
Requirements
Throw-away Executable Prototype +
Prototyping System Specification
Evolutionary prototyping

Develop abstract Build prototype Use prototype

specification system system

Deliver YES System

system adequate?
Evolutionary prototyping advantages

• Accelerated delivery of the system

• Rapid delivery and deployment are sometimes more important than
functionality or long-term software maintainability
• User engagement with the system
• Not only is the system more likely to meet user requirements, they are more
likely to commit to the use of the system
Evolutionary prototyping problems

• Management problems
• Existing management processes assume a waterfall model of development
• Specialist skills are required which may not be available in all development teams
• Maintenance problems
• Continual change tends to corrupt system structure so long-term maintenance is
expensive
• Contractual problems
• Due to cost or time line agreed
Throw-away prototyping

Outline Develop Evaluate Specify

requirements prototype prototype system

Reusable
components

Delivered
Develop Validate software
software system system
Throw-away prototyping
• Used to reduce requirements risk
• The prototype is developed from an initial specification, delivered for experiment
then discarded
• The throw-away prototype should NOT be considered as a final system
• Some system characteristics may have been left out
• There is no specification for long-term maintenance
• The system will be poorly structured and difficult to maintain
Prototyping Methods and Tools
• A prototype must be developed rapidly so that the customer may assess results and recommend
changes.
3 methods are available:
1. Fourth Generation Techniques (4GT)
• 4GT enable the software engineer to generate executable code quickly, they are ideal for rapid
prototyping.
• Ex. Tool for Database query language or reporting language.
2. Reusable software components
• To rapid prototyping is to assemble, rather than build, the prototype by using a set of existing
software components.
• Should maintain library for existing software components
• An existing software product can be used as a prototype for a "new, improved" competitive
product
3. Formal specification and prototyping environments
• Enable an analyst to interactively create language-based specifications of a system or software,
• Invoke automated tools that translate the language-based specifications into executable code,
• Enable the customer to use the prototype executable code to refine formal requirements.