Software Engineering

Module 2
 What is a Requirement?
It may range from a high-level abstract statement
of a service or of a system constraint to a
detailed mathematical functional specification.

This is inevitable as requirements may serve a

dual function
 May be the basis for a bid for a contract - therefore must be open to
interpretation;
 May be the basis for the contract itself - therefore must be defined in
detail;
 Both these statements may be called requirements.

Chapter 4 Requirements engineering 2

 Types of Requirements
User requirements
 Statements in natural language plus diagrams of the services the system
provides and its operational constraints.
 Written for customers.

System requirements
 A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints.
 Defines what should be implemented so may be part of a contract
between client and contractor.
 Whom do you think these are written for?
 These are higher level than functional and non-functional requirements,
which these may subsume.

Chapter 4 Requirements engineering 3

User and System
Requirements

Chapter 4 Requirements engineering 4

 Functional and Non-functional
Requirements
Functional requirements
 Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in
particular situations.
 May state what the system should not do.
Non-functional requirements
 Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
 Often apply to the system as a whole rather than individual features or
services.
Domain requirements
 Constraints on the system from the domain of operation
Chapter 4 Requirements engineering 5
 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.
 Functional system requirements should describe the system
services in detail.
 Essentially, these are the ‘whats’ of the system that we often
refer to. These are not ‘all that there is,’ but these should
describe the overall functionality of the system.

Chapter 4 Requirements engineering 6

Non-functional Requirements
 These define system properties and constraints e.g. reliability,
response time, maintainability, scalability, portability, and
storage requirements.
 Constraints are I/O device capability, system representations,
etc.
 Process requirements may also be specified mandating a
particular IDE, programming language or development
method.
 (Often internal to an organization or required for fit /
compatibility with other comparable systems.)
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system may
be useless.

Chapter 4 Requirements engineering 7

 Non-functional Requirements
Implementation
Non-functional requirements may affect the
overall architecture of a system rather than the
individual components.
 For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between
components.
A single non-functional requirement, such as a
security requirement, may generate a number of
related functional requirements that define
system services that are required.
 It may also generate requirements that restrict existing requirements.
Chapter 4 Requirements engineering 8
 Domain requirements
problems
Understandability
 Requirements are expressed in the language of the application domain;
Application written for mortgage banking people need to express
functionality in terms of home loans, mortgage balances, escrow,
investor accounting, foreclosure, etc.
 This is often not understood by software engineers developing the
system.
Implicitness
 Domain specialists understand the area so well that they do not think of
making the domain requirements explicit.
 And this is often a major problem in communications!!!

Chapter 4 Requirements engineering 9

 Key points
 Requirements for a software system set out what the system
should do and define constraints on its operation and
implementation.
 Functional requirements are statements of the services that the
system must provide or are descriptions of how some
computations must be carried out.
 Non-functional requirements often constrain the system being
developed and the development process being used.
 They often relate to the emergent properties of the system and
therefore apply to the system as a whole.

Chapter 4 Requirements engineering 10

 Example of Functional
Requirements
• The software automatically validates customers against the
ABC Contact Management System
• The Sales system should allow users to record customers
sales
• The background color for all windows in the application
will be blue and have a hexadecimal RGB color value of
0x0000FF.
• Only Managerial level employees have the right to view
revenue data.
• The software system should be integrated with banking
API
11
 Example of Non Functional
Requirements
• Users must change the initially assigned login password immediately
after the first successful login. Moreover, the initial should never be
reused.
• Employees never allowed to update their salary information. Such
attempt should be reported to the security administrator.
• Every unsuccessful attempt by a user to access an item of data shall be
recorded on an audit trail.
• A website should be capable enough to handle 20 million users with
affecting its performance
• The software should be portable. So moving from one OS to other OS
does not create any problem.
• Privacy of information, the export of restricted technologies,
intellectual property rights, etc. should be audited.
12
 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
13
 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

14
 Requirements Engineering
The process of establishing the services that
the customer requires from a system and the
constraints under which it operates and is
developed.

The requirements themselves are the

descriptions of the system services and
constraints that are generated during the
requirements engineering process.
Chapter 4 Requirements engineering 15
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

16
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

17
 Inception Task
• How does a s/w project get started ?
- Business need is identified
- Potential new market or service is
discovered
- Stakeholders (business managers, marketing people, product

managers) define a business case for the idea

- Identify breath and depth of market
- Rough feasibility analysis, identify a working description of
the project’s scope

18
 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

19
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

20
 Elicitation Task
• Ask the customer, the users and others what the objectives
of the system or product are, what is to be accomplished ,
how the system or product fits into the needs of the
business, hoe the system is to be used on a day to day basis
• 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
21
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

22
 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
23
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

24
 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
• Using an iterative approach, requirements are
eliminated, combined and/or modified so that
each party achieves some measure of
satisfaction 25
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

26
 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 27
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

28
 Validation
• Work products produced as a consequence of
requirements engineering are assessed
• Examine the specification to ensure that all s/w
requirements have been stated unambiguously
• Inconsistencies, omissions and errors have been
detected and corrected
• Work product conforms to the standards
established for the process, the project and the
product

29
 Validation
• Primary validation mechanism is the formal
technical review
• Review team – Software Engineers,
Customers, Users and other stakeholders
• Examine the specification looking for errors
in content or interpretation, areas where
clarification may be required , missing info,
inconsistencies .conflicting requirements or
unrealistic requirements.
30
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

31
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

32
Requirements Management Task
• Features Traceability Table – Shows how
requirements relate to important customer
observable system product features
• Source Traceability Table – Identifies the
source of each requirement
• Dependency Traceability Table – Indicates
how requirements are related to one another

33
Requirements Management Task
• Subsystem Traceability Table – Categorizes
requirements by the subsystem(s) that they
govern
• Interface Traceability Table – Shows how
requirements relate to both external and
internal system interfaces.

34
Requirements Traceability Table

35
 Initiating the Requirements
Engineering Process
• Identify the stakeholders
• Recognize multiple viewpoints
• Work toward collaboration
• Break the ice and initiate the
communication

36
 Identify the Stakeholders
• Stakeholder is anyone who benefits in a
direct or indirect way from the system
which is being developed.
• Business Operations Managers, Product
Managers, Marketing People, Internal and
External Customers, End Users,
Consultants, Product Engineer, Software
Engineer, Support and Maintenance
Engineer. 37
 Identify the Stakeholders
• Every stakeholder has a different view of
the system
• Achieves different benefits when the system
is successfully developed
• At inception, Requirements engineer should
create a list of people who will contribute
input as requirements are elicited

38
 Recognize multiple view points
• Explored from different points of view
• Marketing group will be interested in functions and features that
will excite the potential market making new system easy to sell
• Business Managers – interested in a feature set that can be built
within budget
• End Users – features that are familiar to them
• S/W Engineers – Concerned with functions that enable the
infrastructure supporting more marketable functions and
features.
• Support Engineers – may focus on the maintainability of
software.
• Job of requirements engineer is to categorize all stakeholder
information in a way that will allow decision makers to choose
an internally consistent set of requirements.
39
 Working toward Collaboration
• Identify areas of commonality (requirements on
which all stakeholders agree)
• Areas of conflict or inconsistency (requirements
that are desired by one stakeholder but conflicts
with the needs of others )
• Stakeholders collaborate by providing their
view of requirements but a business
manager or Senior technologist may make
the final decision
40
 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?

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

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

43
 Eliciting Requirements
• Collaborative Requirement Gathering
• Quality Function Deployment
• User Scenarios (i.e Use Cases)
• Elicitation Work Products

44
 Basic Guidelines of Collaborative
Requirements Gathering
• 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
45
 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 46
 User Scenarios
• The Scenario often called as “Use-Cases” or “user stories”,
provide a description of how the system will be used.
• As requirements are gathered, an overall vision of system
functions & features begins to materialize.
• However it is difficult to move into more technical software
engineering activities until the software team understands
how these functions & features will be used by different
classes of end-users.
• To accomplish this developers & users create a set of
scenarios that helps to identify a thread of usage for the
system to be constructed.
47
 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
48
 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

(More on next slide) 49

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

50
Use-Case Diagram

51
 Use Case Template

• Use Case:<use-case-title>
• Primary Actor: <primary-actor>
• Goal in Context: <the aim of the primary-actor in a particular circumstance>
• Preconditions: <conditions that must be true before the scenario may play
out>
• Trigger: <an action or actions that initiate the scenario>
• Scenario: <an enumerated list of steps describing the actions and interactions
of the primary actor with the system>
• Exceptions: <errors or faults that may occur during the scenario.
Should include remedy/corrective action taken by the primary actor>

52
Building the Analysis Model

53
 Scenario Based Elements
• System is described from the user’s point of view using a
scenario based approach
• First part of analysis model
• Serve as input for the creation of other modelling elements
• Different approach is to depict activities or functions that
have been defined as part of requirement elicitation task
• Sequence of activities define processing and can be
represented at many different levels of abstraction

54
Activity Diagram for Eliciting
Requirements

55
 Class Based Elements
• Each usage scenario implies a set of objects that
are manipulated as an actor interacts with the
system
• Objects are characterized into classes
• Class diagram lists the attributes and operations
• Depict the manner in which classes collaborate,
relationship and interaction

56
 Behavioral Elements
• Behaviour of a computer based system can have a
profound effect on design and implementation
• Analyis model must provide modelling elements
that depict behaviour
• State Diagram depicts states and events that cause
system to change state. Also what actions are
taken as a consequence of a particular event

57
 Flow Oriented Elements
• System accepts input in a variety of forms , applies
functions to transform it, and produces output in a variety
of forms
• Input – Control signal transmitted by a transducer, series
of numbers, packet of info transmitted on a network link,
data file etc
• Transform – single logical comparison, complex numerical
algorithm, expert system etc

58
 Class Diagram
• Static diagram which represents the static view of
an application. It is not only used for visualizing,
describing, and documenting different aspects of a
system but also for constructing executable code
of the software application.
• Describes the attributes and operations of a class
and also the constraints imposed on the system.
• Class diagram shows a collection of classes,
interfaces, associations, collaborations, and
constraints. It is also known as a structural
diagram. 59
 Class Notation
• Class Name
- The name of the class appears in the first partition.
• Class Attributes
– Attributes are shown in the second partition.
– The attribute type is shown after the colon.
– Attributes map onto member variables (data members) in code.
• Class Operations (Methods)
- Operations are shown in the third partition. They are services the class
provides.
- The return type of a method is shown after the colon at the end of the
method signature.
- The return type of method parameters is shown after the colon following
the parameter name.
- Operations map onto class methods in code 60
Class Notation

61
Class Diagram

62
 Inheritance (or Generalization):
• Represents an "is-a" relationship.
• An abstract class name is shown in italics.
• SubClass1 and SubClass2 are specializations of Super Class.
• A solid line with a hollow arrowhead that point from the child to the
parent class

63
 Simple Association
• A structural link between two peer classes.
• There is an association between Class1 and Class2
• A solid line connecting two classes

64
 Aggregation
• A special type of association. It represents a "part of" relationship.
• Class2 is part of Class1.
• Many instances (denoted by the *) of Class2 can be associated with
Class1.
• Objects of Class1 and Class2 have separate lifetimes.
• A solid line with an unfilled diamond at the association end connected
to the class of composite

65
 Composition
• A special type of aggregation where parts are destroyed
when the whole is destroyed.
• Objects of Class2 live and die with Class1.
• Class2 cannot stand by itself.
• A solid line with a filled diamond at the association
connected to the class of composite

66
 Example
• The diagram on next slide is an example of an Order System of an
application. It describes a particular aspect of the entire application.

• First of all, Order and Customer are identified as the two elements of
the system. They have a one-to-many relationship because a customer
can have multiple orders.

• Order class is an abstract class and it has two concrete classes

(inheritance relationship) SpecialOrder and NormalOrder.

• The two inherited classes have all the properties as the Order class. In
addition, they have additional functions like dispatch () and receive ().

67
Class Diagram

68
Class Diagram

69
 State Diagram
• Used to model the dynamic nature of a system.
• They define different states of an object during its lifetime
and these states are changed by events.
• Statechart diagrams are useful to model the reactive
systems. Reactive systems can be defined as a system that
responds to external or internal events.
• Describes the flow of control from one state to another
state. States are defined as a condition in which an object
exists and it changes when some event is triggered.
• The most important purpose of Statechart diagram is to
model lifetime of an object from creation to termination.

70
 State Chart Diagram
Cont…

– Elements of state chart diagram

– Initial State: A filled circle
– Final State: A filled circle inside a larger
circle
– State: Rectangle with rounded corners
– Transitions: Arrow between states, also
boolean logic condition (guard)
State Chart Diagram

72
An Example of A State Chart
Diagram
order received
Unprocessed
Order
[reject] checked [accept] checked

Rejected Accepted
Order Order
[some items available]
[some items not processed / deliver
available] processed

[all items
Pending available] Fulfilled
Order newsupply Order

Example: State chart diagram for an order object

 Negotiating Requirements
• Customer and developer enter into a process of
negotiation.
• Customer may be asked to balance functionality,
performance and other product or system
characterisics against cost and time to market
• Develop a project plan that meets the needs of the
customer while at the same time reflecting the real
world constraints (time, people, budget)

74
Negotiating Requirements

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

(more on next slide) 76

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?

77
 Summary
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management 78
