Requirements Engineering Process

Requirements Engineering Process

Topic-I

Requirements Engineering Processes

• Processes used to discover, analyse and validate system requirements
Requirements Engineering
• Feasibility —A set of 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 —elicit requirements from all stakeholders
• Elaboration —create an analysis model that identifies data, function and behavioral requirements
• Negotiation —agree on a deliverable system that is realistic for developers and customers
Requirements Engineering
• Specification —can be any one (or more) of the following:
 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
• Validation —a 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.
• Requirements management
 Requirements Engineering Process

The requirements engineering process

Inception / Feasibility
• Identify stakeholders
• Recognize multiple points of view
• Work toward collaboration
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?
Feasibility studies
• A feasibility study decides whether or not the proposed system is worthwhile

• A short focused study that checks

 If the system contributes to organisational objectives
 If the system can be engineered using current technology and within budget
 If the system can be integrated with other systems that are used
Feasibility study Implementation
• Based on information assessment (what is required), information collection and report writing

• Questions for people in the organisation

 What if the system wasn‟t implemented?
 What are current process problems?
 How will the proposed system help?
 Requirements Engineering Process

 What will be the integration problems?

 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?

Eliciting Requirements
• Meetings are conducted and attended by both software engineers and customers
• Rules for preparation and participation are established
• An agenda is suggested
• A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
• A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board,
chat room or virtual forum) is used
• The goal is
 To identify the problem
 Propose elements of the solution
 Negotiate different approaches, and
 Specify a preliminary set of solution requirements

Eliciting Requirements

Conduc t FA ST
m eet ings

Mak e lis t s of
f unc t ions , c las s es

Mak e lis t s of
c ons t raint s , et c .

f orm al priorit iz at ion?

El i c i t re q u i re m e n t s
y es no

Us e QFD t o inf orm ally def ine ac t ors

priorit iz e priorit iz e
requirem ent s requirem ent s

draw us e-c as e
writ e s c enario
diagram

Creat e Us e-c as es
c om plet e t em plat e
 Requirements Engineering Process

The Requirements Analysis

Process

Problems of Requirements Analysis

• 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 analysis process. New stakeholders may emerge and the business
environment change.
Process Activities
• Domain understanding
• Requirements collection
• Classification
• Conflict resolution
• Prioritisation
• Requirements checking
Building the Analysis Model
• Elements of the analysis model
 Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an “actor” and the system
 Class-based elements
• Implied by scenarios
 Requirements Engineering Process
 Behavioral elements
• State diagram
 Flow-oriented elements
• Data flow diagram
System Models
• Different models may be produced during the requirements analysis activity
• Requirements analysis may involve three structuring activities which result in these different models
 Partitioning. Identifies the structural (part-of) relationships between entities
 Abstraction. Identifies generalities among entities
 Projection. Identifies different ways of looking at a problem
Viewpoint-Oriented Elicitation
• Stakeholders represent different ways of looking at a problem or problem viewpoints

• Multi-perspective analysis is important as there is no single correct way to analyse system requirements
Types of Viewpoint
• Data sources or sinks
 Viewpoints are responsible for producing or consuming data. Analysis involves checking that data
is produced and consumed and that assumptions about the source and sink of data are valid
• Representation frameworks
 Viewpoints represent particular types of system model. These may be compared to discover
requirements that would be missed using a single representation. Particularly suitable for real-time
systems
• Receivers of services
 Viewpoints are external to the system and receive services from it. Most suited to interactive
systems
External Viewpoints
• Natural to think of end-users as receivers of system services.

• Viewpoints are a natural way to structure requirements elicitation.

• It is relatively easy to decide if a viewpoint is valid.

• Viewpoints and services may be sued to structure non-functional requirements.

Method-Based Analysis
• Widely used approach to requirements analysis. Depends on the application of a structured method to
understand the system
 Requirements Engineering Process

• Methods have different emphases. Some are designed for requirements elicitation, others are close to
design methods
The VORD method

VORD Process Model

• Viewpoint identification
 Discover viewpoints which receive system services and identify the services provided to each
viewpoint
• Viewpoint structuring
 Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the
hierarchy
• Viewpoint documentation
 Refine the description of the identified viewpoints and services
• Viewpoint-system mapping
 Transform the analysis to an object-oriented design
View point Identification
• Involves Domain Analysis

• Define the domain to be investigated.

• Collect a representative sample of applications in the domain.

• Analyze each application in the sample.

• Develop an analysis model for the objects.

Different View Points
• Data View Point  Data Modeling
• Object View Point  Object Modeling
• Scenario View Point / Behavior View Point
 Scenario Modeling / Event Modeling
• Function View Point  Flow Oriented Modeling
Data Modeling
• Examines data objects independently of processing
 Requirements Engineering Process

• Focuses attention on the data domain

• Creates a model at the customer‟s level of abstraction

• Indicates how data objects relate to one another

Scenario-Based Modeling

“[Use-cases] are simply an aid to defining what exists outside the system (actors) and
what should be performed by the system (use-cases).” Ivar Jacobson

(1) What should we write about?

(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?

Flow-Oriented Modeling

Represents how data objects are transformed at they move through the system
A data flow diagram (DFD) is the diagrammatic form that is used
Exception Description
• Most methods do not include facilities for describing exceptions

• In ATM example, exceptions are:

 Timeout. Customer fails to enter a PIN within the allowed time limit.
 Invalid card. The card is not recognised and is returned.
 Stolen card. The card has been registered as stolen and is retained by the machine.
Social and Organisational Factors
• Software systems are used in a social and organisational context. This can influence or even dominate
the system requirements.

• Social and organisational factors are not a single viewpoint but are influences on all viewpoints.

• Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis.
Ethnography
• Social scientists spend a considerable time observing and analysing how people actually work.

• People do not have to explain or articulate their work.

• Social and organisational factors of importance may be observed.

• Ethnographic studies have shown that work is usually richer and more complex than suggested by
simple system models.
 Requirements Engineering Process

Focused Ethnography
• Combines ethnography with prototyping

• Prototype development results in unanswered questions which focus the ethnographic analysis

• Problem with ethnography is that it studies existing practices which may have some historical basis
which is no longer relevant
Ethnography and Prototyping

Scope of Ethnography
• Requirements that are derived from the way that people actually work rather than the way of processing
definitions suggest that they ought to work

• Requirements that are derived from cooperation and awareness of other people‟s activities
IEEE Standard for Software Requirements Specification

The following SRS outline is based on IEEE 830-1993:

 1. Introduction—This section is intended to provide an overview of the rest of the specification.
 1.1 Purpose—This section must describe the purpose of the SRS and the intended audience.
 1.2 Scope—This section must identify the product, explain what the product will and will not do, and
describe the application of the software, including benefits, objectives, and goals.
 1.3 Definitions—This section must identify all terms, acronyms, and abbreviations used in the
specification.
 1.4 References—This section must identify all documents referenced elsewhere in the specification.
 1.5 Overview—This section must describe what the rest of document contains.

 2. Overall Description —This section is intended to provide the background to understand the rest of the
requirements.
 2.1 Product Perspective —This section must put the product into perspective with other products. It will
usually include a block diagram of the larger system. It should specify constraints (e.g., system interfaces
with other software), user interfaces (e.g., screen formats, timing), hardware interfaces, software
interfaces (e.g., versions of interfaced software), memory constraints, operations (e.g., modes of
operations), and site adaptation constraints.
 Requirements Engineering Process
 2.2 Product Functions —This section must include a summary of the major functions of the product.
 2.3 User Characteristics —This section must include the educational level, experience, and technical
expertise of the users.
 2.4 Constraints —This section must include any other (e.g., regulatory) constraint that is not covered in
Section 2.1.
 2.5 Assumptions and Dependencies —This section must include any assumptions that, if not true, would
require changes to the requirements.
 2.6 Apportioning of Requirements —This section must identify requirements that may be delayed to
future versions of the product.
 3. Specific Requirements —According to IEEE Standard 830: „„This section of the SRS should contain all
the software requirements to a level of detail sufficient to enable designers to design a system to satisfy
those requirements, and testers to test that the system satisfies those requirements.‟‟ The SRS should be
sufficiently detailed so designs and tests can be constructed directly from the SRS.
 „„These requirements should include at a minimum a description of every input (stimulus) into the
system, every output (response) from the system and all functions performed by the system in response to
an input or in support of an output.‟‟
 3.1 External Interface Requirements —This section must describe all inputs and outputs of the system.
This gives detailed Product information
 3.2 Functions—This section must describe all the functions of the system. These must include validity
checks on inputs, responses to abnormal situations, effect of parameters, and the relationship of outputs to
inputs.
 3.3 Performance Requirements —This section must describe the static and dynamic requirements.
 3.4 Design Constraints —This section must describe any constraints on the design.
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?
 Requirements Engineering Process
• 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.
• Have requirements patterns been used to simplify the requirements model. Have all patterns been
properly validated? Are all patterns consistent with customer requirements?
Requirements Checking
• Validity. Does the system provide the functions which best support the customer‟s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and technology
• Verifiability. Can the requirements be checked?
Requirements validation techniques
• Requirements reviews
 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 the consistency of a structured requirements description
Requirements reviews
• Regular reviews should be held while the requirements definition is being formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal (with completed documents) or informal. Good communications between
developers, customers and users can resolve problems at an early stage.

Review checks
• Verifiability. Is the requirement realistically testable?
• Comprehensibility. Is the requirement properly understood?
• Traceability. Is the origin of the requirement clearly stated?
• Adaptability. Can the requirement be changed without a large impact on other requirements?
 Requirements Engineering Process

Automated Consistency Checking

Requirements Management
• Requirements management is the process of managing changing requirements during the requirements
engineering process and system development
• Requirements are inevitably incomplete and inconsistent
 New requirements emerge during the process as business needs change and a better understanding
of the system is developed
 Different viewpoints have different requirements and these are often contradictory
Requirements Change
• The priority of requirements from different viewpoints changes during the development process

• System customers may specify requirements from a business perspective that conflict with end-user
requirements

• The business and technical environment of the system changes during its development
 Requirements Engineering Process

Requirements Evolution

Enduring and Volatile Requirements

• Enduring Requirements: Stable requirements derived from the core activity of the customer
organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models

• Volatile Requirements: Requirements which change during development or when the system is in use. In
a hospital, requirements derived from health-care policy
Classification of requirements
• Mutable requirements
 Requirements that change due to the system‟s environment
• Emergent requirements
 Requirements that emerge as understanding of the system develops
• Consequential requirements
 Requirements that result from the introduction of the computer system
• Compatibility requirements
 Requirements that depend on other systems or organisational processes
Requirements Management Planning
• During the requirements engineering process, you have to plan:
 Requirements identification
• How requirements are individually identified
 A change management process
• The process followed when analysing a requirements change
 Traceability policies
 Requirements Engineering Process
• The amount of information about requirements relationships that is maintained
 CASE tool support
• The tool support required to help manage requirements change
CASE Tool Support
• Requirements storage
 Requirements should be managed in a secure, managed data store
• Change management
 The process of change management is a workflow process whose stages can be defined and
information flow between these stages partially automated
• Traceability management
 Automated retrieval of the links between requirements
Requirements change management
• Should apply to all proposed changes to the requirements

• Principal stages
 Problem analysis. Discuss requirements problem and propose change
 Change analysis and costing. Assess effects of change on other requirements
 Change implementation. Modify requirements document and other documents to reflect change

Requirements Change Management