INTRODUCTION TO

SOFTWARE ENGINEERING
Daniyal Ahmed
THE REQUIREMENTS PROCESS

 A requirement is an expression of desired behaviour

 Requirements focus on the customer needs, not on the solution or
implementation
 designate what behaviour, without saying how that behaviour will be
realized
THE REQUIREMENTS PROCESS
SIDEBAR: WHY ARE REQUIREMENTS IMPORTANT?

 Top factors that caused project to fail

 Incomplete requirements
 Lack of user involvement
 Unrealistic expectations
 Lack of executive support
 Changing requirements and specifications
 Lack of planning
 System no longer needed
 Some part of the requirements process is involved in all of
the causes
 Requirements error can be expensive if not detected early
THE REQUIREMENTS PROCESS

 Performed by the req. analyst or system analyst

 The final outcome is a Software Requirements Specification
(SRS) document

Process for Capturing Requirements

 REQUIREMENTS ELICITATION

 Customers do not always understand what their needs and

problems are
 It is important to discuss the requirements with everyone who has
a stake in the system
 Come up with agreement on what the requirements are
 If we cannot agree on what the requirements are, then the project is
doomed to fail
 REQUIREMENTS ELICITATION

 Different Stakeholders are:

 Clients: pay for the software to be developed
 Customers: buy the software after it is developed
 Users: use the system
 Domain experts: familiar with the problem that the software
must automate
 Market Researchers: conduct surveys to determine future
trends and potential customers
 Lawyers or auditors: familiar with government, safety, or legal
requirements
 Software engineers or other technology experts
REQUIREMENTS ELICITATION
SIDEBAR: USING VIEWPOINTS TO MANAGE INCONSISTENCY

 No need to resolve inconsistencies early in the requirements

process (Easterbrook and Nuseibah, 1996)
 Stakeholders' views documented and maintained as
separate Viewpoints through the software development
process
 The requirements analyst defines consistency rules that should apply
between Viewpoints
 The Viewpoints are analyzed to see if they conform to the consistency
requirements
 Inconsistencies are highlighted but not addressed until there
is sufficient information to make informed decision
REQUIREMENTS ELICITATION

 Means to Elicit Requirements:

 Interviewing stake holders
 Reviewing available documentations
 Observing the current system (if one exists)
 Apprenticing with users to learn about user's task in more details
 Interviewing user or stakeholders in groups
 Using domain specific strategies, such as Joint Application Design, or
PIECES
 Brainstorming with current and potential users
REQUIREMENTS ELICITATION

 The Volere requirements process model suggests some

additional sources for requirements
TYPES OF REQUIREMENTS

 Functional requirement
 Describes: interaction between the system and its environment, how should the
system behave given certain stimuli, required behaviour in terms of required
activities
 Example: For a system of printing pay cheques the functional requirements must
answer the following:
 When are pay cheques issued?
Both types of
 What input is necessary for a pay cheque to be printed?

requirements
 Quality requirement or non-functional requirement are elicited
 Describes: some quality characteristic that the software must posses, a restriction on
the system that limits our choices from the customer
for constructing a solution in a
 Constraints could be:
 Design constraint: a design decisionformal,
such as choice of careful way.
platform or interface components
 Process constraint: a restriction on the techniques or resources that can be used to build the
system
 Example: queries to the system must be answered within 3 seconds
TYPES OF REQUIREMENTS

 Two kinds of Requirement Documents

 Requirements definition: a complete listing of everything the
customer wants to achieve
 Describing the entities in the environment where the system will be installed
 Requirements specification: restates the requirements as a
specification of how the proposed system shall behave
 Primarily used by our technical team
PRIORITIZING REQUIREMENTS

 Different stakeholder has different set of requirements

 potential conflicting ideas
 Need to prioritize requirements to resolve conflicts
 Prioritization might separate requirements into three categories
 essential: absolutely must be met
 desirable: highly desirable but not necessary
 optional: possible but could be eliminated
LECTURE
CHARACTERISTICS OF
REQUIREMENTS
 Correct
 Consistent
 Unambiguous
 Complete
 Feasible
 Relevant
 Testable
 Traceable
TESTABLE REQUIREMENTS

 Testable/Measurable Requirement:
 Objective description of the requirement’s meanings
 All possible entities and activities can be examined and classified as
Meet Requirements and Do Not Meet Requirements
 Testable requirements are helpful in making good design
 Requirements that are not testable are likely to be ambiguous,
incomplete and incorrect
TESTABLE REQUIREMENTS

 Robertson and Robertson suggest 3 ways to help make

requirements testable:
 Specify a quantitative description for each adverb and adjective
 Replace pronouns with specific names of entities
 Make sure that every noun is defined in exactly one place in the
requirements document
TESTABLE REQUIREMENTS

 Some examples:
 Not Testable: Water quality information must be accessible immediately
 Testable: Water quality information must be retrieved within five
seconds of request
 Not Testable: The system should handle a large number of users at a
time
 Testable: The system should handle 5000 users at a time
 Not Testable: User should press the Save button when writing text in
the system. This prevents it from being lost.
 Testable: User should press the Save button when writing a note in the
system. Pressing the Save button prevents the text from being lost.
EXPRESSING REQUIREMENTS

 A requirement deals with

 objects or entities
 the state they can be in
 functions that are performed to change states or object characteristics

 It is important to have standard notations for modelling,

documenting, and communicating decisions
 Modelling helps us to understand requirements thoroughly
 Holes in the models reveal unknown or ambiguous behaviour
 Multiple, conflicting outputs to the same input reveal inconsistencies in
the requirements
EXPRESSING REQUIREMENTS

 Dynamic Descriptions of a System

 Decision Tables
 State Diagrams (Statecharts)
 Fence Diagrams
 Event Tables
 Petri Nets
 Event Traces (Message Sequence Charts)
 Static Descriptions of a System
 Object Models (ER Diagrams, Abstract class diagrams)
 Other Techniques to Express Requirements
 Data Flow Diagrams (DFD)
 Usecase Diagrams
DECISION TABLES

 It is a tabular representation of a functional specification that

maps events and conditions to appropriate reponses or action
 The specification is formal because the inputs (events and
conditions) and outputs (actions) may be expressed in natural
language
 If there is n input conditions, there are 2n possible combination of
input conditions
 Combinations map to the same set of result can be combined into
a single column
DECISION TABLES (CONTD.)

 Decision table for library functions borrow, return, reserve,

and unreserve
STATE DIAGRAMS

 A graphical description of all dialog between the system and its

environment
 Node (state) represents a stable set of conditions that exists between
event occurences
 Edge (transition) represents a change in behavior or condition due to
the occurrence of an event
 Useful both for specifying dynamic behavior and for describing
how behavior should change in response to the history of events
that have already occurred
STATE DIAGRAMS (CONTD.)

 Finite state machine model of the tunstile problem

STATE DIAGRAMS (CONTD.)

 A path: starting from the machine's initial state and following

transitions from state to state
 A trace of observable events in the environment
 Deterministic state machine: for every state and event there is
a unique response
STATE DIAGRAMS (CONTD.)

 Ways of thinking about State

 Equivalence classes of possible future behavior
 Periods of time between consecutive event
 Named control points in an object's evolution
 Partition of an object's behavior
STATE DIAGRAMS: UML NOTATION
STATE DIAGRAMS: UML STATECHART

 A UML statechart diagram depicts the dynamic behaviour of the

objects in a UML class
 UML class diagram has no information about how the entities behave,
how the behaviours change
 A UML model is a collection of concurrently executing statecharts
 UML statechart diagram have a rich syntax, including state
hierarchy, concurrency, and inter-machine communication
UML STATECHART DIAGRAM

 State hierarchy is used to unclutter diagrams by collecting into

superstate those states with common transitions
 A superstate can actually comprise multiple concurrent
submachines, separated by dashed line
 The submachines are said to operate concurrently
 Students can recall the activity of reducing a DFA, or converting a
DFA to a RE during Automata Course
UML STATECHART DIAGRAM

 The UML statechart diagram for the Publication class

from the Library class model
UML STATECHART DIAGRAM

 An equivalent statechart for Publication class that does not make use
of state hierarchy or concurrency
 comparatively messy and and repetitive
UML STATECHART DIAGRAM EXAMPLE

 The UML state diagram for Hotel Reservation

FENCE DIAGRAM