Week 2

Requirement Engineering
Requirement Engineering Processes
Indranil Saha
Department of Computer Science and Engineering

Indian Institute of Technology Kanpur
CS253: Software Development and Operations Requirement Engineering 1/8

Includes four high-level activities.
Feasibility study: Assess if the system is useful to the

business
Elicitation and analysis: Discover requirements
Specification: Convert these requirements into some

standard form
Validation: Check that the requirements actually define

the system that the customer wants

The Spiral View

Feasibility Study
Does the system contribute to the overall objectives of the

organization?
Can the system be implemented within schedule and

budget using current technology?
Can the system be integrated with other systems that are

used?

Requirement Elicitation and Analysis
Software engineers work with customers and system

end-users to find out about
the application domain
what services the system should provide
the required performance of the system
hardware constraints
...
People involved (stakeholders) are

end-users who will interact with the system
engineers who are developing or maintaining other related
systems
business managers
domain experts
trade union representatives

Requirement Elicitation and Analysis Process

Challenges
Stakeholders’ vague understanding of the requirements
Lack of domain experience of the requirement engineers
Repeating and conflicting requirements from different

stakeholders
Political factors in the organization
Dynamism of the economic and business environment

Indranil Saha


Requirement Discovery
Indranil Saha


Requirements Discovery
The process of gathering information about the required

system and existing systems, and distilling the user and
system requirements from this information
Sources of information during the requirements discovery

phase include
documentation
specifications of similar systems
system stakeholders
You interact with stakeholders through interviews and

observation and you may use scenarios and prototypes to
help stakeholders understand what the system will be like

Example of Stakeholders for the MHC-PMS
Patients
Doctors
Nurses
Medical receptionists
IT staff
Medical ethics manager
Healthcare managers

Interviewing
Formal and informal interviews with all the stakeholders
Interviews may be
closed interviews
open interviews
Information from interviews supplements other information

about the system from documentation describing business
processes or existing systems, user observations, etc.
Sometimes, interview may be the only source of

information about the system requirements

Challenges
Stakeholders are bound to use jargons
Extremely familiar domain knowledge may be missed
Internal politics

Scenarios
Useful for adding detail to an outline requirements

description
Descriptions of example interaction sessions
Each scenario usually covers one or a small number of

possible interactions

Content of a Scenario
A description of what the system and users expects when

the scenario starts
A description of the normal flow of events in the scenario
A description of what can go wrong and how this is handled
Information about other activities that might be going on at

the same time
A description of the system state when the scenario

finishes

Example Scenario for Collecting Medical History in
MHC-PPMS

Requirement Discovery
Indranil Saha


Requirement Validation
Indranil Saha


The process of checking that requirements actually define

the system that the customer really wants
Overlaps with analysis as it is concerned with finding

problems with the requirements
Important because errors in a requirements document can

lead to extensive rework costs when these problems are
discovered during development or after the system is in
service
- The cost of fixing a requirements problem by making a
system change is usually much greater than repairing
design or coding errors

Requirements Validation Checks
Consistency checks
Completeness check
Realism check
Verifiability

Requirement Validation Techniques
Requirements reviews
Prototyping
Test-case generation

Indranil Saha


Architectural Design
Introduction to Architectural Design
Indranil Saha

CS253: Software Development and Operations Architectural Design 1/6

The critical link between design and requirements

engineering
Identifies the main structural components in a system and

the relationships between them
The output is an architectural model that describes how

the system is organized as a set of communicating
components
The goal is to design a system organization that will satisfy

the functional and non-functional requirements of a system

Example: Architecture of a Packing Robot Control
System

Connection with Requirement Engineering
Architectural decomposition is usually necessary to

structure and organize the specification
An abstract system architecture help associate groups of

system functions or features with large-scale components
or sub-systems
Use this decomposition to discuss the requirements and

features of the system with stakeholders
The nonfunctional requirements depend on the system

architecture — the way in which these components are
organized and communicate

Architectural Design Decisions
Is there a generic application architecture that can act as a
template for the system that is being designed?
How will the system be distributed across a number of
cores or processors?
What architectural patterns or styles might be used?
What will be the fundamental approach used to structure
the system?
How will the structural components in the system be
decomposed into subcomponents?
What strategy will be used to control the operation of the
components in the system?
What architectural organization is best for delivering the
non-functional requirements of the system?
How will the architectural design be evaluated?
How should the architecture of the system be
documented?
Introduction to Architectural Design
Indranil Saha


Architectural Pattern
Indranil Saha


Architectural Patterns
A way of presenting, sharing, and reusing knowledge

about software systems is now widely used.
A stylized, abstract description of good practice, which has
been tried and tested in different systems and
environments.
Describe a system organization that has been successful
in previous systems.
Include information of when it is and is not appropriate to
use that pattern, and the pattern’s strengths and
weaknesses.

Pattern Presentation
Pattern name
A brief description (with an associated graphical model)
An example of the type of system where the pattern is
used (again, perhaps with a graphical model)
Information about when the pattern should be used
Its advantages and disadvantages

Architectural Pattern
Indranil Saha


Model-View-Controller and Layered Architecture Pattern
Indranil Saha


Model-View-Controller Pattern

Model-View-Controller Pattern - Contd.
When Used:
When there are multiple ways to view and interact with data
When the future requirements for interaction and
presentation of data are unknown
Advantages:
Allows the data to change independently of its
representation and vice versa
Supports presentation of the same data in different ways
with changes made in one representation shown in all of
them
Disadvantages:
Can involve additional code and code complexity when the
data model and interactions are simple

Layered Architecture Pattern

Layered Architecture Pattern - Contd.
When Used:
When building new facilities on top of existing systems
When the development is spread across several teams with
each team responsibility for a layer of functionality
When there is a requirement for multi-level security
Advantages:
Allows replacement of entire layers as long as the interface
is maintained
Redundant facilities (e.g., authentication) can be provided
in each layer to increase the dependability of the system
Disadvantages:
Providing a clean separation between layers is often difficult
- a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately
below it
Performance degradation due to multiple levels of
interpretation of a service request as it is processed at each
layer
Model-View-Controller and Layered Architecture Pattern
Indranil Saha


Repository Architecture Pattern
Indranil Saha


Repository Architecture

Repository Architecture - Contd.
When Used:
In a system in which large volumes of information are
generated that has to be stored for a long time
In data-driven systems where the inclusion of data in the
repository triggers an action or tool
Advantages:
Components can be independent — they do not need to
know of the existence of other components
Changes made by one component can be propagated to all
components
All data can be managed consistently (e.g., backups done
at the same time) as it is all in one place
Disadvantages:
The repository is a single point of failure
Inefficiencies in organizing all communication through the
repository
Distributing the repository across several computers may
be difficult
Repository Architecture Pattern
Indranil Saha


Client-Server and Pipe-and-Filer Architecture Patterns
Indranil Saha


Client-Server Architecture
Example: A Film Library

Client-Server Architecture - Contd.
When Used:
When data in a shared database has to be accessed from a
range of locations
Advantages:
The servers can be distributed across a network
General functionality (e.g., a printing service) can be
available to all clients and does not need to be implemented
by all services
Disadvantages:
Each service is a single point of failure so susceptible to
denial of service attacks or server failure
Performance may be unpredictable because it depends on
the network as well as the system
May be management problems if servers are owned by
different organizations

Pipe and Filter Architecture
Example: Invoice Processing System

Pipe and Filter Architecture - Contd.
When Used:
Commonly used in data processing applications where
inputs are processed in separate stages to generate related
outputs
Advantages:
Easy to understand and supports transformation reuse
Workflow style matches the structure of many business
processes
Evolution by adding transformations is straightforward
Can be implemented as either a sequential or concurrent
system
Disadvantages:
The format for data transfer has to be agreed upon between
communicating transformations
- impossible to reuse functional transformations that use
incompatible data structures.
Client-Server and Pipe-and-Filer Architecture Patterns
Indranil Saha


Application Architectures
Indranil Saha


Transaction Processing System

Example: The Software Architecture of an ATM
System

Information System

Example: The Architecture of the MHC-PMS

Language Processing System

Example: A Pipe and Filter CompilerArchitecture

A Repository Architecture of a Language Processing
System

Application Architectures
Indranil Saha


Week 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Week 2

Uploaded by

Copyright:

Available Formats

Requirement Engineering

Requirement Engineering Processes

Department of Computer Science and Engineering

CS253: Software Development and Operations Requirement Engineering 1/8

Includes four high-level activities.

Feasibility study: Assess if the system is useful to the

Elicitation and analysis: Discover requirements

Specification: Convert these requirements into some

Validation: Check that the requirements actually define

CS253: Software Development and Operations Requirement Engineering 2/8

CS253: Software Development and Operations Requirement Engineering 3/8

Does the system contribute to the overall objectives of the

Can the system be implemented within schedule and

Can the system be integrated with other systems that are

CS253: Software Development and Operations Requirement Engineering 4/8

Software engineers work with customers and system

People involved (stakeholders) are

CS253: Software Development and Operations Requirement Engineering 5/8

CS253: Software Development and Operations Requirement Engineering 6/8

Stakeholders’ vague understanding of the requirements

Lack of domain experience of the requirement engineers

Repeating and conflicting requirements from different

Political factors in the organization

Dynamism of the economic and business environment

CS253: Software Development and Operations Requirement Engineering 7/8

Department of Computer Science and Engineering

CS253: Software Development and Operations Requirement Engineering 8/8

Department of Computer Science and Engineering

CS253: Software Development and Operations Requirement Engineering 1/9

The process of gathering information about the required

Sources of information during the requirements discovery

You interact with stakeholders through interviews and

CS253: Software Development and Operations Requirement Engineering 2/9

Medical ethics manager

CS253: Software Development and Operations Requirement Engineering 3/9

Formal and informal interviews with all the stakeholders

Information from interviews supplements other information

Sometimes, interview may be the only source of

CS253: Software Development and Operations Requirement Engineering 4/9

Stakeholders are bound to use jargons

Extremely familiar domain knowledge may be missed

CS253: Software Development and Operations Requirement Engineering 5/9

Useful for adding detail to an outline requirements

Descriptions of example interaction sessions

Each scenario usually covers one or a small number of

CS253: Software Development and Operations Requirement Engineering 6/9

A description of what the system and users expects when

A description of the normal flow of events in the scenario

A description of what can go wrong and how this is handled

Information about other activities that might be going on at

A description of the system state when the scenario

CS253: Software Development and Operations Requirement Engineering 7/9

CS253: Software Development and Operations Requirement Engineering 8/9

Department of Computer Science and Engineering

CS253: Software Development and Operations Requirement Engineering 9/9

Department of Computer Science and Engineering

CS253: Software Development and Operations Requirement Engineering 1/5

The process of checking that requirements actually define

Overlaps with analysis as it is concerned with finding

Important because errors in a requirements document can

CS253: Software Development and Operations Requirement Engineering 2/5

CS253: Software Development and Operations Requirement Engineering 3/5