Requirements Engineering

• Requirements: Requirements Engineering,

UML Model, Developing Use Cases, Building
the Requirements Model, Negotiating
Requirements, Validating Requirements.

1
 Multiple problem viewpoints

Database administrator
Customer

Problem to
be analysed

Manager
Marketing

2
 Requirements Engineering

- Problems with requirements practices

- Requirements engineering tasks
- Inception
- Elicitation
- Elaboration
- Negotiation
- Specification
- Validation
- Requirements management
The Problems with our Requirements Practices

• We have trouble understanding the requirements that we do acquire

from the customer

• We often record requirements in a disorganized manner

• We spend far too little time verifying what we do record

• We allow change to control us, rather than establishing mechanisms

to control change

• Most importantly, we fail to establish a solid foundation for the

system or software that the user wants built

4
The Problems with our Requirements Practices
(continued)
• Many software developers argue that
– Building software is so compelling that we want to jump right in (before having
a clear understanding of what is needed)
– Things will become clear as we build the software
– Project stakeholders will be able to better understand what they need only after
examining early iterations of the software
– Things change so rapidly that requirements engineering is a waste of time
– The bottom line is producing a working program and that all else is secondary
• All of these arguments contain some truth, especially for small projects that
take less than one month to complete
• However, as software grows in size and complexity, these arguments begin
to break down and can lead to a failed software project

5
 INTRODUCTION
► Requirements Engineering is the process of understanding and defining
what services are required from the system and identifying the constraints
on the system’s operation and development.
► Requirements engineering is a particularly critical stage of the software
process as errors at this stage inevitably lead to later problems in the
system design and implementation.

What are requirements?

» A requirement can be a description of what a system must do.

» A requirement is a singular documented need of what a particular
product or service should be or do.

6
 Contd….
» Defined at early stages of a system development Includes:
─ how the system should behave?
─ application domain information
─ constraints on the system's operation
─ specification of a system property or attribute.

»A collection of requirements define the characteristics or features of the

desired system.

» A 'good' list of requirements generally avoids saying how the system

should implement the requirements, leaving such decisions to the system
designer. Describing how the system should be implemented is known as
implementation bias.

»A software requirements specification (SRS) is a complete description

of the behavior of the system to be developed. It includes a set of use cases
that describe all of the interactions that the users will have with the
software.
7
 What is requirements engineering?
➢ A relatively new term invented to cover all of the activities
involved in discovering, documenting and maintaining a set of
requirements for a computer-based system.

➢ Use of the term 'engineering' implies that systematic and

repeatable techniques should be used to ensure that system
requirements are complete, consistent and relevant.
 Types of requirement
• User requirements
– Statements in natural language plus diagrams of the
services and its operational constraints. Written for
customers
• System requirements
– A structured document setting out detailed descriptions
of the system services. Written as a contract between
client and contractor
• Software specification
– A detailed software description which can serve as a
basis for a design or implementation. Written for
developers
 Requirements readers
Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects

System end-users
Client engineers
System requirements
System architects
Software developers

Client engineers (perhaps)

Software design
System architects
specification
Software developers
Functional and non-functional requirements

• Functional requirements
– Statements of services the system should provide,
• how the system should react to particular inputs
• how the system should behave in particular situations.

• Non-functional requirements
– constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.

• Domain requirements
– Requirements that come from the application domain of the
system and that reflect characteristics of that domain
Functional requirements
• Describe functionality or system services
• Depend on the type of software, expected users and the type of system where
the software is used
• Functional user requirements may be high-level statements of what the
system should do but functional system requirements should describe the
system services in detail
Examples:
• The user shall be able to search either all of the initial set of databases or
select a subset from it.
• The system shall provide appropriate viewers for the user to read documents
in the document store.
• Every order shall be allocated a unique identifier (ORDER_ID) which the
user shall be able to copy to the account’s permanent storage area.
Non-functional requirements

Define system properties and constraints

reliability, response time, storage requirements, ...
I/O device capability, system representations, ...

Can define process requirements

specific CASE system (e.g. Rational Rose)
programming language
development method

Non-functional requirements may be more critical than

functional requirements. If these are not met, the system is
useless.
Non-functional Requirements classifications
• Product requirements
– Requirements which specify that the delivered product
must behave in a particular way e.g. execution speed,
reliability, etc.
• Organisational requirements
– Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
• External requirements
– Requirements which arise from factors which are external
to the system and its development process e.g.
interoperability requirements, legislative requirements, etc.
Non-functional Requirement Types
Non-functional
requirements

Product Organizational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements
Examples:
Product requirement
The user interface for LIBSYS shall be implemented as
simple HTML without frames or Java applets

Organisational requirement
The system development process and deliverable documents
shall conform to the process and deliverables defined in
XYZCo-SP-STAN-95

External requirement
The system shall not disclose any personal information
about customers apart from their name and reference number
to the operators of the system
why do we care?

❖ Requirements clashes

❖ Requirements ambiguities

❖ Granularity issues
 Requirements Engineering Process
➢ The main goal of the requirements engineering process is to create and
maintain a system requirements document.

➢ Establishing what the customer requires from a software system

The process of establishing the:

services that the customer requires from a system
constraints under which the system operates
constraints under which the system is developed.

➢ Process activities:
Mainly the process encompasses
– Software specification
– Software design and implementation
– Software validation
– Software evolution
 Actors in requirements engineering process

• Domain expert: provide information about the application domain

and the specific problem in that domain which is to be solved

• System end-user: will use the system after delivery

• Requirements engineer: eliciting and specifying the requirements

• Software engineer: responsible for developing the software system

• Project manager: planning and estimating the prototyping project

 Software specification
The requirements engineering process is shown in below figure.
▪ This process describes the production of a requirements document that is the
Specification for the system.
▪ Requirements are usually presented at two levels of detail in this document.
1.End-users and customers need a high-level statement of requirements.
2.System developers need a more detailed system specification.
➢ There are four main phases in the Requirements Engineering Process:

» Feasibility study;
» Requirements elicitation and analysis;
» Requirements specification;
» Requirements validation.
Fig1. The requirements engineering process
1.Feasability Study:
A feasibility study focuses on
» An estimate is made of whether the customer/user may be satisfied using the
current software and hardware technologies.
» Does the system be contribute to the overall objectives of the
organization.
» Whether it can be developed within existing budgetary constraints.
» Can the system be integrated with other systems which are already in place

2.Requirements elicitation and analysis:

» In this phase the analyst must understood the system requirements and
deriving the requirements through observation of existing systems,
potential users and task analysis.
» It will be helpful in development of one or more system models and prototypes.
3.Requirements Specification:
It is also called as software requirement specification(SRS). It describes two types
of requirements.
➢ User requirements are abstract statements of the system
requirements

➢ System requirements are the more detailed description of the

functionality to be provided.
4.Requirements Validation

▪ This phase checks the requirements for realism, consistency, and

completeness.

▪ Also it is helpful to modify the errors in choosing the requirements.

 The Software Requirements Document
It is also called as Software Requirement Specification(SRS).
• The requirements document is the official statement of what is required of
the system developers
• It should include both a definition and a specification of requirements
• It is NOT a design document. As far as possible, it should set of WHAT the
system should do rather than HOW it should do it

➢ The requirements document has a diverse set of users, ranging from the
senior management of the organization that is paying for the system to the
engineers responsible for developing the software.
➢ The various set of possible users means that the requirements document has
to be a cooperation between communicating the requirements to customers,
defining the requirements in exact detail for developers ,testers and
maintenance engineers.
 Users of a requirements document
Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements

Use the requirements

Managers document to plan a bid for
the system and to plan the
system development process

Use the requirements to

System engineers understand what system is to
be developed

System test Use the requirements to

engineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
engineers the relationships between its
parts
• There are many different ways to structure the requirements
documents, depending on:

» The type of the system being developed

» The level of detail included

» Organizational practice

» Budget

» Schedule
1.IEEE/ANSI 830 - 1993 Standards:
1.Introduction
1.Purpose of the requirements document.
2.Scope of the product
3.Definitons, acronyms and abbreviations
4.References
5.Overview of the remainder of the document
2.General description
1.Product perspective
2.Product functions
3.User characteristics
4.General constraints
5.Assumptions and dependences
3.Specific requirements
1.Functional requirements
2.Non-Functional requirements
3.Interface requirements
4.Appendices
5.Index
2. Requirements document structure:
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index
Explanation:

Introduction (Requirements Definition)

Describe need for the system and how it fits with business
objectives.
Functional Requirements
Describe the services to be provided in detail.
Non-functional Requirements
Define constraints on the system and the development
process.
System Evolution
Define fundamental assumptions on which the system is
based and anticipated changes.
Glossary
Define technical terms used.
 A Solution: Requirements Engineering

• Begins during the communication activity and continues into the modeling
activity
• Builds a bridge from the system requirements into software design and
construction
• Allows the requirements engineer to examine
– the context of the software work to be performed
– the specific needs that design and construction must address
– the priorities that guide the order in which work is to be completed
– the information, function, and behavior that will have a profound impact on the
resultant design

30
Requirements Engineering Tasks
• Seven distinct tasks
– Inception
– Elicitation
– Elaboration
– Negotiation
– Specification
– Validation
– Requirements Management
• Some of these tasks may occur in parallel and all are adapted to the
needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and
construction of the software

31
Example Project: Campus Information Access Kiosk

• Both podium-high and desk-high terminals located throughout the campus

in all classroom buildings, admin buildings, labs, and dormitories
• Hand/Palm-login and logout (seamlessly)
• Voice input
• Optional audio/visual or just visual output
• Immediate access to all campus information plus
– E-mail
– Cell phone voice messaging

32
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

33
 Inception Task

• 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

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

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

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

37
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

38
 Elicitation Task

• Eliciting requirements is difficult because of

– Problems of scope in identifying the boundaries of the system or specifying too
much technical detail rather than overall system objectives
– Problems of understanding what is wanted, what the problem domain is, and what
the computing environment can handle (Information that is believed to be
"obvious" is often omitted)
– Problems of volatility because the requirements change over time

• Elicitation may be accomplished through two activities

– Collaborative requirements gathering
– Quality function deployment

39
 Basic Guidelines of Collaborative
Requirements Gathering
• Meetings are conducted and attended by both software engineers,
customers, and other interested stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas
• A "facilitator" (customer, developer, or outsider) controls the meeting
• A "definition mechanism" is used such as work sheets, flip charts, wall
stickers, electronic bulletin board, chat room, or some other virtual
forum
• The goal is to identify the problem, propose elements of the solution,
negotiate different approaches, and specify a preliminary set of
solution requirements

40
 Quality Function Deployment
• This is a technique that translates the needs of the customer into
technical requirements for software
• It emphasizes an understanding of what is valuable to the customer
and then deploys these values throughout the engineering process
through functions, information, and tasks
• It identifies three types of requirements
– Normal requirements: These requirements are the objectives and goals
stated for a product or system during meetings with the customer
– Expected requirements: These requirements are implicit to the product
or system and may be so fundamental that the customer does not
explicitly state them
– Exciting requirements: These requirements are for features that go
beyond the customer's expectations and prove to be very satisfying when
present

41
 Elicitation Work Products

The work products will vary depending on the system, but should include one or
more of the following items
• A statement of need and feasibility
• A bounded statement of scope for the system or product
• A list of customers, users, and other stakeholders who participated in
requirements elicitation
• A description of the system's technical environment
• A list of requirements (organized by function) and the domain
constraints that apply to each
• A set of preliminary usage scenarios (in the form of use cases) that
provide insight into the use of the system or product under different
operating conditions
• Any prototypes developed to better define requirements

42
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

43
 Elaboration Task
• 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

44
 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

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

46
Building the Analysis Model: 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

47
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

48
 Negotiation Task

• 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

49
 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

50
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

51
 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

52
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

53
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

54
 Validation Task

• 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

55
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? 56
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

57
 Requirements Management Task

• During requirements management, the project team performs a set of

activities to identify, control, and track requirements and changes to
the requirements at any time as the project proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more traceability tables
• These tables may be stored in a database that relate features,
sources, dependencies, subsystems, and interfaces to the
requirements
• A requirements traceability table is also placed at the end of the
software requirements specification

58