Ch-3

Requirement Engineering/
Elicitation
 Topics to be covered

 What are Software requirement and its types?

 What is requirement engineering

 Requirements Engineering Process

 SRS


What is a requirement?
 The software requirements are description of features and
functionalities of the target system and needed by a user to solve a
problem or achieve an objective.
 A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed documents.
 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 for a system are the descriptions of what the
system should do—the services that it provides and the
constraints on its operation..
 Types of Software Requirements
 The requirements, which are commonly considered, are classified
into three categories, namely:

1. Functional requirements:

2. Non-functional requirements

3. Domain requirements
Types of Software Requirements
Functional requirements
IEEE defines functional requirements as ‘a function that a system or
component must be able to perform.’ These requirements describe
the interaction of software with its environment and specify the
inputs, outputs, external interfaces, and the functions that should be
included in the software. These are statements of services the system
should provide, how the system should react to particular inputs, and
how the system should behave in particular situations.
It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what
function a system is likely to perform.
Functional requirements expressed in user stories, features, and
capabilities represent most of the work in building solutions that
deliver value to the user. Functional Requirements are also called
Functional Specification.
Types of Software Requirements
Functional requirements
 Functional requirements can be consider in to the following groups:
 Business requirements. describe why the organization is undertaking the
project. This usually contains the ultimate goal, such as an order system,
approval workflows, an online catalogue, or a physical product.
 Administrative functions. These are the routine things the system will do,
such as reporting.
 User requirements. referred to as user needs, describe what the user does
with the system, such as what activities that users must be able to perform,
such as place an order or browse the online catalogue.
 System requirements. are the building blocks developers use to build the
system. These are the traditional “shall” statements that describe what the
system “shall do” .These are things like software and hardware
specifications, system responses, or system actions.
 Types of Software Requirements
Functional requirements should include the following
things:
Details of operations conducted in every screen
Data handling logic should be entered into the system
It should have descriptions of system reports or other outputs
Complete information about the workflows performed by the system
It should clearly define who will be allowed to create/modify/delete
the data in the system
How the system will fulfill applicable regulatory and compliance
needs should be captured in the functional document.
 The functional requirements should be complete and
consistent.
 Completeness implies that all the user requirements are defined.
 Consistency implies that all requirements are specified clearly
without any contradictory definition.
Examples of functional requirements
 The list of examples of functional requirements
includes:
 Business Rules
 Transaction corrections, adjustments, and cancellations
 Administrative functions
 Authentication
 Authorization levels
 Audit Tracking
 External Interfaces
 Certification Requirements
 Reporting Requirements
 Types of Software Requirements
Nonfunctional Requirements
A non-functional requirement defines the quality attribute of a
software system. They represent a set of standards used to judge
the specific operation of a system.
Defines how a system is supposed to be. They are user visible
aspects of the system not directly related to functional behavior of
the system.
Nonfunctional requirements are other properties or characteristics
that the system must have, other than its basic functionality.
A non-functional requirement is essential to ensure the usability
and effectiveness of the entire software system. Failing to meet
non-functional requirements can result in systems that fail to
satisfy user needs.
Non-functional requirements are product properties and focus on
user expectations.
Types of Software Requirements
Nonfunctional Requirements
 They are implicit or expected characteristics of software, which
users make assumption of.
 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 classifications
Nonfunctional Requirements
Non-functional classifications

 Nonfunctional Requirements includes:

 Security  Cost
 Logging  Interoperability
 Storage  Flexibility
 Configuration  Disaster recovery
 Performance  Accessibility
Examples of non-functional requirements
Here, are some examples of non-functional requirement:
1. Users must change the initially assigned login password
immediately after the first successful login. Moreover, the initial
should never be reused.
2. Employees never allowed to update their salary information. Such
attempt should be reported to the security administrator.
3. Every unsuccessful attempt by a user to access an item of data shall
be recorded on an audit trail.
4. A website should be capable enough to handle 20 million users with
out affecting its performance
5. The software should be portable. So moving from one OS to other
OS does not create any problem.
6. Privacy of information, the export of restricted technologies,
intellectual property rights, etc. should be audited.
Types of Software Requirements
Domain requirements:
 Domain requirements may be new functional requirements,
constraints on existing requirements or define specific computations.
They are important because they often reflect fundamentals of the
application domain.
 Domain requirements reflect the environment in which the system
operates so, when we talk about an application domain we mean
environments such as train operation, medical records, e-commerce etc.
 When domain requirements are not expressed clearly, it can result in the
following difficulties.
 Understandability
 When domain requirements are specified in the language of application
domain (such as mathematical expressions), it becomes difficult for software
engineers to understand them.
 Implicitness
 When domain experts understand the domain requirements but do not
express these requirements clearly, it may create a problem (due to
incomplete information) for the development team to understand and
implement the requirements in the system.
 why requirements elicitation is difficult:
15

 Problems of scope-The boundary of the system is ill-defined or

the customers/users specify unnecessary technical detail that
may confuse, rather than clarify, overall system objectives.
 Problems of understanding- The customers/users are not
completely sure of what is needed, have a poor understanding
of the capabilities and limitations of their computing
environment, don’t have a full understanding of the problem
domain, have trouble communicating needs to the system
engineer, omit information that is believed to be “obvious,”
specify requirements that conflict with the needs of other
customers/users, or specify requirements that are ambiguous or
untestable.
 Problems of volatility- The requirements change over time.
Requirements Engineering Process
Requirements Engineering
 The process to gather the software requirements from client,
analyze, and document them is known as requirement
engineering.

 The process by which customer needs are understood and

documented and expressed “what” is to be built and “how” it is
to be built.
 Requirement Engineering is the disciplined application of proven
principles, methods, tools, and notations to describe a proposed
system’s intended behavior and its associated constraints. It is
defining the requirements of the system under construction.
 The goal of requirement engineering is to develop and maintain
sophisticated and descriptive ‘System Requirements
Specification’ document.
 Requirements Engineering Process
 Software requirements engineering is the process of determining
what is to be produced in a software system.
 In developing a complex software system, the requirements
engineering process has the widely recognized goal of determining
the needs for, and the intended external behavior, of a system
design.
 Requirements engineering is an important aspect of any software
project, and is a general term used to encompass all the activities
related to requirements. The four specific steps in software
requirements engineering process are:
* Requirements elicitation
* Requirements analysis
* Requirements specification
* Requirements validation
 RE Process-Requirements elicitation
 Requirements elicitation is the practice of researching and
discovering the requirements of a system from users, customers,
and other stakeholders. The practice is also sometimes referred to as
"requirement gathering".
 Elicitation
activities gather all the requirements by posing the
questions “what”, “why” and “who” dimensions.
 The process of acquiring (eliciting) all the relevant knowledge
needed to produce a requirements model of a problem domain. This
implies that requirements elicitation is all about 'understanding by
user and customer' some particular problem domain.
 RE Process-Requirements elicitation
Requirements Gathering Sources
 Domain knowledge
The software engineer needs to be knowledgeable of the application
domain
Allows for assessment which is not articulated
 Stakeholders – Also known as Process Actors
The software engineer needs to identify, represent, and manage the
‘viewpoints’ of many different types of stakeholders
 The operational environment
The environment that software will be executed in will reveal
system constraints and system element interoperability
 Example: timing constraints in real-time software or
interoperability constraints in an office environment.
 The organizational environment
New software should not force unplanned change on the business
process.
RE Process-Requirements elicitation
 The system developers and engineers work in a close relationship
with the customers and end-users. Elicitation techniques
facilitates this process by,
 determining more about the problem statement to be solved
 Describing the functionalities and non functional attributes.
 Application domain understanding: is knowledge of the general area
where the system is applied.
 Business understanding: You must understand how systems interact
and contribute to overall business goals.
 Understanding the needs, constraints and Boundaries of system.
 Enhances the performance of the system.
 A set of acceptance criteria
 Bridges the gap between the stakeholders and the developers.
 RE Process-Requirements elicitation Process
 Requirement Elicitation: The client, the developers and the users identify a
problem area and define a system that addresses the problem. Requirement
elicitation process can be depicted using the following diagram:

 Requirements gathering - The developers discuss with the client and end
users and know their expectations from the software.
 Organizing Requirements - The developers prioritize and arrange the
requirements in order of importance, urgency and convenience.
 Negotiation & discussion - If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, it is then negotiated and
discussed with the stakeholders. Requirements may then be prioritized and
reasonably compromised.
 Documentation - All formal and informal, functional and non-functional
requirements are documented and made available for next phase processing.

RE Process-Requirements elicitation Techniques
 Once requirements sources have been identified, the software
engineer can start eliciting requirements from them. Even if
sources are cooperative and articulate, the relevant information
must be captured.
 A variety of techniques can be used such as:
 Brainstorming
 Interviews
 Questionnaires
 Prototypes
 Scenarios
 Facilitated
meetings
 Observation
RE Process-Requirements elicitation Techniques
 Brainstorming- Planned brainstorming generates a few imaginative
ideas around a specific key demand or territory.
 Interviews– Talk with stakeholders who you think can give essential
knowledge into the requirements.
 Questionnaires- is a research instrument consisting of a series of
questions for the purpose of gathering information from respondents.
 Prototypes– From paper mock-ups of screen designs to beta-test
versions of software products.
 Scenarios – Provides a context for elicitation of user requirements.
 Asks ‘what if’ and ‘how is this done’ questions
 The most common type of scenario is the use case ("who" can do
"what" with the system in question).
 Facilitated meetings –A group of people may bring more insight to
achieve a summative effect to the requirements
 Observation – Software engineers are immersed in the environment
to observe the user interact between the software and other users
 RE Process-Requirements analysis
 Requirements analysis: IEEE defines requirements analysis as
 The process of studying user needs to arrive at a definition of a
system, hardware or software requirements.
 Requirements analysis helps to understand, interpret, classify, and
organize the software requirements in order to assess the feasibility,
completeness, and consistency of the requirements.
 The process of reasoning about the requirements that have been
elicited; it involves activities such as examining requirements for
conflicts or inconsistencies, combining related requirements and
identifying missing requirements.
 The goal of analysis is to discover problems, incompleteness and
inconsistencies in the elicited requirements.
 Assessing if the system is useful to the business (feasibility study),
 RE Process-Requirements analysis
 After
requirement gathering, requirement analysis is done to check
on why the product is needed. Requirement analysis includes:
 Necessity checking – requirements that don’t contribute to the business
goals of the organization or specific problem that has to be addressed
by the system are checked for necessity for the development of the
system.
 Consistency and completeness checking – no contradictions and
feasibility checking in terms of budget and schedule.
 Requirement discussion – highlight the requirement and discussion of
problematic elements through introspection and interviews.
 Requirement prioritization – requirements are prioritized based on
criticality and the highly complex and critical activities are identified
for risk plot and low level activities are considered for easy
implementation.
 Requirement agreement – compromised set of requirements based on
feasibility checking.
 Analysis model is built incrementally and iteratively.
 RE Process-Requirements specification
 Requirement specification describes clearly and accurately each of the
essential requirements (functions, performance, design constraints, and
quality attributes) of the system and its external interfaces.
 Requirements specification is the process of writing down the user and
system requirements in a requirements document.
User requirements have to be understandable by end-users and customers
who do not have a technical background.
System requirements are more detailed requirements and may include
more technical information.
 Specification involves representing and storing the collected requirements
knowledge in a persistent and well-organized fashion that facilitates
effective communication and change management. Use cases, user
stories, functional requirements, and visual analysis models are popular
choices for requirements specification.
 RE Process-Requirements specification
A software requirements specification (SRS) is a document that
captures complete description about how the system is expected to
perform. It is usually signed off at the end of requirements engineering
phase.
 SRS defines how the intended software will interact with hardware,
external interfaces, speed of operation, response time of system,
portability of software across various platforms, maintainability, speed of
recovery after crashing, Security, Quality, Limitations etc. Converting
these requirements into some standard form (specification/SRS),
 SRS should come up with the following features:
User Requirements are expressed in natural language.
Technical requirements are expressed in structured language, which is
used inside the organization.
Design description should be written in Pseudo code.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.
 RE Process-Requirement Validation
 Requirements validation is the process of checking that
requirements defined for development, define the system that the
customer really wants. After requirement specifications are
developed, the requirements mentioned in this document are
validated.
 We usually use requirements validation to check error at the initial
phase of development as the error may increase excessive rework
when detected later in the development process.
 User might ask for illegal, impractical solution or experts may interpret
the requirements inaccurately. This results in huge increase in cost if
not nipped in the bud.
 Validation involves techniques to confirm that the correct set of
requirements has been specified to build a solution that satisfies the
project's business objectives.
 RE Process-Requirement Validation
Requirements validation can be checked against following criteria:
 Correctness:
 The requirements should reflect the actual needs of the stakeholders.
 A specification is correct if it represents accurately the system that
the client needs and that the developers intend to build.
 Completeness:
 They should include descriptions of all facilities/services required.
 It is complete if all possible scenarios through the system are
described, including exceptional behavior.
 Consistency:
 There should be no conflicts or contradictions in the descriptions of
the system facilities.
 Unambiguous/Clarity:
 A requirement cannot be interpreted in two mutually exclusive ways.
 The requirements specification is unambiguous if exactly one
system is defined.
30
 RE Process-Requirement Validation
 Realism:
 Requirements can be implemented and delivered
 The requirements specification is realistic if the system can be
implemented within constraints.
 Verifiability/Measurable / Testable :
 The requirements specification is verifiable if, once the system is
built, repeatable tests can be designed to demonstrate that the system
fulfills the requirements specification.
 Traceability
 A requirements specification is traceable if each requirement can be
traced throughout the software development to its corresponding
system functions, and if each system function can be traced back to
its corresponding set of requirements.

31
RE Process-Requirement Validation Techniques
 There are some techniques you can use to validate the
requirements, and you may use one or more of them together,
depending on your needs. Requirements validation techniques:
Requirements reviews
Prototyping

Model validation
Test-case generation
RV/Requirements Reviews
A systematic manual analysis of the requirement. Validation often
done by inspection or reviews of requirements documents.
Reviewers look for errors, mistaken assumptions, lack of clarity,
and deviation from standard practice.
 Regular reviews should be held while the requirements definition
is being formulated. What to look for:
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?
RV/Prototyping
 In this approach to validation, an executable model of the system
is demonstrated to the customer and end users to validate, and
ensure if it meets their needs.
 Prototyping is usually used when the requirements aren’t clear. So,
we make a quick design of the system to validate the requirements.
If it fails, we then refine it, and check again, until it meets the
customer needs.
 This definitely will decrease the cost as a result of having a clear,
understandable, consistent requirements.
RV/Model Validation
 Model validation is defined as “the set of processes and
activities intended to verify that models are performing as
expected, in line with their design objectives, and business
uses.”
 It also identifies “potential limitations and assumptions, and
assesses their possible impact.” Validation activities are
performed by individuals independent of model development or
use.
 Validating the quality of models developed during analysis by
checking different validation criteria.
RV / Test-case generation
 Test case generation is the process of building test suites for
detecting system errors. A test suite is a group of relevant test
cases bundled together. Developing tests for requirements to
check testability.
 The requirements specified in the SRS document should be
testable. Test case generation is the most important and
fundamental process of software testing.
 Requirements Engineering Process

Figure: The requirements engineering process

 Requirements elicitation activities

Requirements elicitation includes the following activities:

 Identifying actors -During this activity, developers identify the different
types of users the future system will support.
 Identifying scenarios - During this activity, developers observe users and
develop a set of detailed scenarios for typical functionality provided by
the future system.
 Scenarios are concrete examples of the future system in use.
 Developers use these scenarios to communicate with the user and deepen their
understanding of the application domain.
 Identifying use cases- Once developers and users agree on a set of
scenarios, developers derive from the scenarios a set of use cases that
completely represent the future system.
38
 Cont’d

 Refining use cases- During this activity, developers ensure that the
requirements specification is complete by detailing each use case
and describing the behavior of the system in the presence of errors
and exceptional conditions.
 Identifying relationships among use cases- During this activity,
developers identify dependencies among use cases. They also
consolidate the use case model by factoring out common
functionality.
 This ensures that the requirements specification is consistent.
 Identifying nonfunctional requirements- During this activity,
developers, users, and clients agree on aspects that are visible to the
user, but not directly related to functionality. These include
constraints on the performance of the system, its documentation, the
resources
39 it consumes, its security, and its quality.
 i) Identifying Actors

 This serves both to define the boundaries of the system and to find all the viewpoints from
which the developers need to consider the system.
 Actors are outside of the system boundary- they are external Subsystems and objects are inside
the system boundary- they are internal
 To identify an actor, search in the problem statement for business terms that represent
roles in the system. For example, in the statement "patients visit the doctor in the clinic
for medical tests," "doctor" and "patients" are the business roles and can be easily
identified as actors in the system.
Questions for identifying actors
 Which user groups are supported by the system to perform their work?
 Which user groups execute the system’s main functions?
 Which user groups perform secondary functions, such as maintenance and administration?
 With what external hardware or software system will the system interact?
40
 Actors are role abstractions and do not necessarily directly map to persons
 Example- Accident Management System

 Potential actors- Fire fighter, police officer, dispatcher, investigator,

mayor, governor, an EPA hazardous material database, system
administrator, and so on
 We then need to consolidate this list into a small number of actors, who
are different from the point of view of the usage of the system.
 A fire fighter and a police officer may share the same interface to the system, as
they are both involved with a single incident in the field. A dispatcher, on the other
hand, manages multiple concurrent incidents and requires access to a larger amount
of information.
 The mayor and the governor will not likely interact directly with the system, but
will use the services of a trained operator instead

41
 ii) Identifying Scenarios

 a specific path through the use case)

 A specific actor ...
 At a specific time ...
 With specific data …
 Many scenarios may be generated from a single use case description
 A scenario is “a narrative description of what people do and experience
as they try to make use of computer systems and applications” [Carroll,
1995]
 A scenario is a concrete, focused, informal description of a single
feature of the system from the viewpoint of a single actor.
 Scenarios enhance requirements elicitation by providing a tool that is
understandable to users and clients.
42
 Cont..

 A use case includes primary and secondary scenarios

 1 primary scenario: Normal course of events
 0 or more secondary scenarios
 Alternative/exceptional course of events, variations of primary scenario
 An alternative scenario meets the intent of the use case but with a different
sequence of steps
 An exceptional scenario addresses the conditions of main case and
 alternative cases that differ from the norm and cases already covered
 Example with consensus as a goal
 Primary scenario: vote in a session
 Alternative scenario: voting in several sessions
 Exceptional scenario: what to do with a non-registrant who wishes to vote
43
 Cont’d

Questions for identifying scenarios

 What are the primary tasks that the system needs to perform?
 What data will the actor create, store, change, remove or add in the
system?
 What external changes does the system need to know about?
 What changes or events will the actor of the system need to be
informed about?
Developers use existing documents (user manuals of previous
systems, procedures manuals, company standards, user, user and client
interviews) about the application domain to answer these questions.
The emphasis for developers during actor identification and scenario
identification is to understand the application domain.
44
 Example- Accident Management System

Your Task (Problem Statement):

Build a requirements model for a system that allows to report fire
incident. It should be able to report incidents for many types of
buildings and things.
The approach: Start with single Scenario, e.g. “Warehouse in fire”.
Interview Guideline:
 What do you need to do if a person reports “Warehouse on Fire?”
 Who is involved in reporting an incident?
 What does the system do, if no fire cars are available?
 Can the system deal with a simultaneous incident report “Warehouse on
Fire?”
 What do you need to do if the “Warehouse on Fire” turns into a “Cat in
the Tree”?
45
 Scenario:
Example - Warehouse on Fire
 Bob, driving down main street in his patrol car notices smoke coming
out of a ware house. His partner, Alice, reports the emergency from her
car by using the SYSTEM.
 Alice enters the address of the building, a brief description of its
location (i.e., north west corner), and an emergency level. In addition to
a fire unit, she requests several paramedic units on the scene given that
area appear to be relatively busy. She confirms her input and waits for
an acknowledgment.
 John, the Dispatcher, is alerted to the emergency by a beep of his
workstation. He reviews the information submitted by Alice and
acknowledges the report. He allocates a fire unit and two paramedic
units to the Incident site and sends their estimated arrival time (ETA) to
Alice. Alice received the acknowledgment and the ETA.
46
 Observations about “Warehouse on
Fire
 Concrete scenario
 Describes a single instance of reporting a fire incident.
 Does not describe all possible situations in which a fire can be
reported.
 Participating actors
 Bob, Alice and John

47
 Observations about “Warehouse on
Fire”
… ok, but we have even more scenarios available and
identified:
 Report fire in a car
 Report flat on fire
 Report truck on fire

 Next step: aggregate/ combine these scenarios

towards a clear use case to describe the possible
sequence of events to “report a fire incident”

48
 iii) Identifying Use Cases

 Define system boundary (subject), actors, and use cases

 Subject could be: a physical system, a component, a subsystem, a class
 To structure and relate use cases
 Associate actors with use cases
 Include relation
 Extend relation
 Generalization (of actors and use cases)
 A scenario is an instance/illustration of a use case; that is, a use case specifies all
possible scenarios for a given piece of functionality.
 A use case is initiated by an actor.

49
 Use Case:
Example – Report Emergency

 The Fireman on duty notices a fire incident. The Fireman or his Replacement (hereafter
termed Initiator) reports the emergency from their car by using the SYSTEM.
 The Initiator enters the address of the corresponding fireplace, a brief description of its
location (i.e., north west corner), and an emergency level. In addition to a fire unit, the
Initiator requests several paramedic units on the scene. He confirms his input and waits
for an acknowledgment.
 The Dispatcher on duty, is alerted to the emergency by a beep of his workstation. He
reviews the information submitted by the Initiator and acknowledges the report. He
allocates a fire unit and a suitable number of paramedic units to the Incident site and
sends their estimated arrival time back to the Initiator.
 The Initiator receives the acknowledgment and the ETA.

50
 Observations about “Report
Emergency”

 A more abstract use case

 Describes a potentially huge number of instances of reporting a fire
incident,
 Describe all possible situations in which a fire can be reported.
 Participating actors
 Initiator, Fireman, Representative

51
 From Scenarios to use cases

 Use case: an abstraction of possible coherent scenarios

 Scenario: a single example of a scenario
 instance of a use case!

Use case
“ReportEmergency”
________________
“ReportEmergency”
_________________
________________

Scenario Scenario Scenario

“Report Warehouse on Fire” “Report Flat on Fire” “Report Car on Fire”
________________ ________________ ________________
_________________ _________________ _________________
________________ ________________ ________________

52
Order of steps when formulating use cases
 First step: Name the use case
 Use case name: ReportEmergency ( Report who, what)
 Second step: Find the actors
 Generalize the concrete names (“Bob”) to participating actors (“Field officer”)
 Participating Actors:
 Field Officer (Bob and Alice in the Scenario)
 Dispatcher (John in the Scenario)
 Third step: Concentrate on the flow of events
 Use informal natural language

53
Use case flow of events
Use case Name ReportEmergency

Actors Initiated by FieldOfficer, communicates with Dispatcher

Flow of events Initiated by FieldOfficer, communicates with Dispatcher

1. The FieldOfficer activates the ReportEmergency function on this
terminal
2. SYSTEM responds by presenting a dialog form to the
FieldOfficer
3. FieldOfficer completes and submitts the form
4. SYSTEM receives the form, evaluates the information in
interaction with a Dispatcher and sends an Acknowledge
Entry condition The FieldOfficer is logged into the SYSTEM
Exit condition The FieldOfficer receives an acknowledge
Quality The FieldOfficer‘s request is acknowlegded within 30
requirements seconds.
• The Dialog form should be implemtented by using
Java SWING classes
54
Simple Use Case Writing Guide
 Use cases should be named with verb phrases. The name of the use
case should indicate what the user is trying to accomplish (e.g.,
ReportEmergency, OpenIncident).
 Actors should be named with noun phrases (e.g., FieldOfficer,
Dispatcher, Victim).
 The boundary of the system should be clear. Steps accomplished by
the actor and steps accomplished by the system should be
distinguished.
 Use case steps in the flow of events should be phrased in the active
voice. This makes it clear who accomplished the step.

55
Cont’d
 The causal relationship between successive steps should be clear.
 A use case should describe a complete user transaction (e.g., the
ReportEmergency use case describes all the steps between initiating
the emergency reporting and receiving an acknowledgment).
 Exceptions should be described separately.
 A use case should not describe the user interface of the system. This
takes away the focus from the actual steps accomplished by the user
and is better addressed with visual mock-ups (e.g., the
ReportEmergency only refers to the “Report Emergency” function,
not the menu, the button, nor the actual command that corresponds to
this function).
 A use case should not exceed two or three pages in length. Otherwise,
use include and extend relationships to decompose it in smaller use
cases

56
iv) Identifying Relationships among Actors and Use Cases
 Relationships among actors and use cases enable the developers
and users to reduce the complexity of the model and increase its
understandability
 Relationship between an actor and use case  communication
relationships
 Relationship between use cases  include relationships (to
reduce redundancy among use cases) and extended relationships
(to separate exceptional and common flows of events)

57
 Cont’d

 Heuristics for extend and include relationships

 Use extend relationships for exceptional, optional, or seldom-occurring
behavior. An Example -the notification of nearby resources responding
to an unrelated incident.
 Use include relationships for behavior that is shared across two or more
use cases.
 However, use discretion when applying the above two heuristics and do
not over structure the use case model. A few longer use cases (e.g., two
pages long) are easier to understand and review than many short ones
(e.g., ten lines long).

58
 v) Identifying Nonfunctional Requirements
 Nonfunctional requirements describe aspects of the system that
are not directly related to its functional behavior.
 Nonfunctional requirements span a number of issues, from user
interface look and feel to response time requirements to security
issues

59
 Examples of non functional requirements

Usability
 What is the level of expertise/ know-how of the user?
 What user interface standards are familiar to the user?
 What documentation should be provided to the user?
Reliability (including robustness, safety, and security)
 How reliable, available, and robust should the system be?
 Is restarting the system acceptable in the event of a failure?
 How much data can the system loose?
 How should the system handle exceptions?
 Are there safety requirements of the system?
 Are there security requirements of the system?
Performance
 How responsive should the system be?
 Are any user tasks time critical?
 How many concurrent users should it support?
 How large is a typical data store for comparable systems?
60
 Case Study
 For our case study, we will be the architects assigned the task of constructing the
design elements for a system that can be used to manage courses/classes for an
organization that specializes in providing training. Let us name the system that we will
be designing as the Courseware Management System. The organization offers a variety
of courses in a variety of areas such as learning management techniques and
understanding different software languages and technologies. Each course is made up
of a set of topics. Tutors in the organization are assigned courses to teach according to
the area that they specialize in and their availability. The organization publishes and
maintains a calendar of the different courses and the assigned tutors every year. There
is a group of course administrators in the organization who manage the courses
including course content, assign courses to tutors, and define the course schedule. The
training organization aims to use the Courseware Management System to get a better
control and visibility to the management of courses as also to streamline the process
of generating and managing the schedule of the different courses.
The organization allow regular and extension students to register for training course
online and to pay for courses by Credit Card, by Cash, by Check etc.
 Now that we have our problem statement defined, we can proceed to the next
step—analyzing and elaborating on the requirements(requirement elicitation
activities) and then designing the Courseware Management System.
61
 UML Case study—Courseware Management
System
 We will now design the use case model for the Courseware Management System
case study.
 Analyze the problem statement to identify the potential actors and use cases of the
system. First, let us list the potential actors.
 A quick look at the problem statement shows up the following terms and entities
specific to the system:
Courses and Topics that make up a course
Tutors who teach courses
Course administrators who mange the assignment of the courses
to tutors
Calendar or Course Schedule is generated as a result of the
Students who refer to the Course schedule or Calendar to decide
which courses they wish to take up for study
Identifying Actors of the Courseware Management System

 The entities that perform action will be the actors for the
Courseware Management System.
 From carefully study of the problem, the actors that we can identify are:
Tutors
Course administrators
Students
 A primary actor among these is:
Course administrators
 Identifying Use Cases of the Courseware Management System

 Next, let us identify the potential business processes in the Courseware Management
System.
 The primary business flows in the system are:
 Manage courses
 Manage course assignments
 We can further divide the above two business flows into sub flows:
 So, within the "Manage courses" use case, we can identify the following sub processes:
 View courses
 Manage topics for a course
 Manage course information
 the use cases that we have identified within the "Manage course assignment" use case
are:
 View course calendar
 View tutors
 Manage tutor information
 Assign courses to tutors
 UCD

 The final list of use cases for the courseware management system will now be:
 View courses
 Manage topics for a course
 Manage course information
 View course calendar
 View tutors
 Manage tutor information
 Assign courses to tutors
 REGISTER ONLINE
 PAYMENT
Example 2: Point of Sell (POS) System in Minimar
 Writing a Use Case Specification
 A use case diagram, as we have seen, is a visual depiction of
the different scenarios of interaction between an actor and a
use case. The usefulness of use case diagrams is more as a
tool of communication between the requirements capture
team and the user group.
 The next step after finalizing of use case diagrams is to document the
business functionality into clear-cut and detailed use case
specifications. Because use cases are used as an input to the other
project phases such as design, development, and testing, we need to
ensure that the visual depiction of the business requirements is
translated into clear and well-defined requirements in the form of use
case specifications. Elaborate use case specifications are used as an
input for design and development and for writing test cases (unit,
system,
67 and regression tests, as the case may be).
 Cont..

 A use case specification document should enable us to easily document the business
flow. Information that you document in a use case specification includes what actors are
involved, the steps that the use case performs, business rules, and so forth.
 A use case specification document should cover the following areas(use case
specification document contents):
• Use Case Name: Give a short, descriptive name to the use case
• Actors: List the actors that interact and participate in this use case.
• Description: Give a short informal description
• Trigger: Describe the event that initiates the activity

68
 Use case specification document
contents…
 Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform.
 Post-conditions: Define the different states in which you expect the system to be in,
after the use case executes.
 Basic Flow: List the basic events that will occur when this use case is executed.
Include all the primary activities that the use case will perform.
 Alternative flows: Any subsidiary events that can occur in the use case should be
listed separately. Each such event should be completed in itself to be listed as an
alternative flow. A use case can have as many alternative flows as required. But
remember, if there are too many alternative flows, you need to revisit your use case
design to make it simpler and, if required, break the use case into smaller discrete
units.
 Special Requirements: Business rules for the basic and alternative flows should be
listed as special requirements in the use case narration. These business rules will also
be used for writing test cases. Both success and failure scenarios should be described
here.
 Use case relationships: For complex systems, it is recommended that you document
the relationships between use cases. If this use case extends from other use cases or
includes the functionality of other use cases, these relationships should be listed here.
Requirements Validation

 Requirements validation is a critical step in the development process, usually after

requirements engineering or requirements analysis. Also at delivery (client
acceptance test).
 Requirements validation criteria:
 Correctness:
 The requirements represent the client’s view.
 Completeness:
 All possible scenarios, in which the system can be used, are described, including exceptional
behavior by the user or the system
 Consistency:
 There are functional or nonfunctional requirements that contradict each other
 Realism:
 Requirements can be implemented and delivered
 Traceability:
 Each system function can be traced to a corresponding set of functional requirements

70
 Requirements Management
 Functional requirements:
 Store the requirements in a shared repository
 Provide multi-user access to the requirements
 Automatically create a specification document from the requirements
 Allow change management of the requirements
 Provide traceability of the requirements throughout the artifacts of the system.
Use Case Templates – Simple Column Form
Linear sequences (main and alternatives)

1. A User inserts a card in the Card reader slot.

2. The system asks for a personal identification number (PIN).
3. The User enters a PIN.
4. The System checks that the user identification is valid.
5. The System asks the user to chose an operation

1.a The Card is not valid.

1.a.1. The System ejects the Card.
4.a The User identification is not valid.
4.a.1 The System ejects the Card.
Use Case Development – Example: ATM
System (1)
1. Determine candidate system scope and boundaries
 Identify stakeholders
 Identify problem - Create problem statement
 Use interviews and other techniques

ATMs + ATM
ATMs
Bank Software

1 2 3
- Customer - Customer - Card reader
- Bank - Cash dispenser
- Key pad
- Touch screen
- Printer
- Bank
Use Case Development – Example: ATM System
(2)
2. Identify actors
 Who interacts with the system? Example ATM with scope 2
 Who or what uses the system?
 For what goals? Bank Customer
 What roles do they play?

 Who installs the system?

 Who or what starts and shuts Installation Technician
down the system? Administrator
 Who maintains the system?
 Who or what gets and provides Administrator
information to the system?
 Does anything happen at a fixed time? Bank
 Check for possible actor generalization Weekly Reports
Use Case Development – Example: ATM System
(3)
2. Identify actors (cont’d)
 Choose actors’ names carefully
 Actors give value, get value from system or both
 Should reflect roles rather than actual people
 An actor specifies a role an external entity adopts when it interacts directly with your
system
 People / things may play multiple roles simultaneously or over time
 Use right level of abstraction

Poor act or nam e Good act or nam e

Clerk Pension Clerk
Third-level supervisor Sale supervisor
Data Entry Clerk #165 Product accountant
Eddie “The Dawg” Taylor Customer service representative
 Use Case Development – Example: ATM System
(4)
3. Identify use cases Example actor: Customer
 Identify and refine actors’ goals Goal: Access account for
 Why would actor AAA use the system? regular banking operations
 Identify actors’ tasks to meet goals (withdrawal, deposit, statement...)
in a timely and secure way.
 What interactions would meet goal GGG
of actor AAA? To be refined into sub-goals.
 Chose appropriate use case names
From goals we can identify tasks:
 Verb-noun construction Withdraw Cash, Make Deposit,
 No situation-specific data Print Account Statement....
 Not tied to organization structure, paper forms, computer implementation, or manual process (e.g.,
enter form 104-B, complete approval window, get approval from immediate supervisor in Accounting
Department)
Use Case Development – Example: ATM System
(5)
3. Identify use cases (cont’d)
 Develop a brief description in narrative form
 e.g., description of use case Withdraw Cash

The Customer identifies herself to the system, then selects the

cash withdrawal operation. The system asks for the amount to
withdraw. The Customer specifies the amount. The system
provides the requested amount. The Customer takes the amount
and leaves.

4. Identify preconditions
 e.g., preconditions of use case Withdraw Cash
 System is in operation, cash is available
 Use Case Development – Example: ATM System
(6)

5. Definition of primary scenario

 Happy day story where everything goes fine
6. Definition of secondary scenarios (alternatives/exceptions)
 A method for finding secondary scenarios is to go through the primary scenarios and ask:
 Is there some other action that can be taken at this point? (alternate scenario)
 Is there something that could go wrong at this point? (exception scenario)
 Is there some behavior that could happen at any time? (alternative scenario unless it is an error, then it
would be an exception scenario)

Example use case: Withdraw Cash

• Not enough cash available
• Incorrect identification
• Customer forgets card in card reader
• Incorrect amount entered
• Customer forgets cash in dispenser
Use Case Development – Example: ATM System
(7)
7. Structure use case diagram
 Identify commonalities and specify included use cases
 Identify variants and specify extended use cases

Withdraw Cash

Identify Customer Bank

<<include>>

<<include>> <<include>>

Customer
Make Deposit
Print Account Statement
Example 1

80
 Name: Enroll in University
 Identifier: UC 19
 Goal: Enroll applicant in the university
 Preconditions:
 The Registrar is logged into the system.
 The Applicant has already undergone initial checks to verify that they are eligible to enroll.
 Postconditions:
 The Applicant will be enrolled in the university as a student if they are eligible.

81
 Main Flow:
 1. An applicant wants to enroll in the university.
 2. The applicant hands a filled out copy of form UI13 University Application Form to the
registrar.
 3. The registrar visually inspects the forms.
 4. The registrar determines that the forms have been filled out properly.
 5. The registrar selects to Create New Student.
 6. The system displays the Create Student Screen.
 7. The registrar inputs the name, address, and phone number of the applicant.
 [Extension Point: XPCheck]
 8. The system determines that the applicant does not already exist within the system.
 9. The system determines that the applicant is on the eligible applicants list.
 10. The system adds the applicant to its records.
 11. The registrar enrolls the student in courses via use case UC 17 Enroll in
 Course.
 12. The system prepares a bill for the applicant enrollment fees.
 Alternate Flows:
 4.a The forms have not been adequately filled…

82
 Name: Perform Security Check
 Identifier: UC 34
 At Extension Point XPCheck:
 1. The registrar asks for security check results about applicant.
 2. The system asks RCMP Security System for applicant security check results.
 3. The RCMP Security System responds that applicant has been cleared.
 3.a The Security System responds that applicant has not been cleared

83
The software requirements document
A software requirements document (also known as software
requirements specifications) is a document that describes the intended use-case,
features, and challenges of a software application.
 The output of the requirements phase of the software development process
is Software Requirements Specification (SRS) (also known
as requirements document). This document lays a foundation for software
engineering activities and is created when entire requirements are elicited and
analyzed. SRS is a formal document, which acts as a representation of software
that enables the users to review whether it (SRS) is according to their
requirements. In addition, it includes user requirements for a system as well as
detailed specifications of the system requirements.
 IEEE defines software requirements specification as, ‘a document that clearly
and precisely describes each of the essential requirements (functions,
performance, design constraints and quality attributes) of the software and the
external interfaces. Note that requirements specification can be in the form of a
written document, a mathematical model, a collection of graphical models, a
prototype, and so on.
Why software document requirements?
 Softwarerequirement documents provide an important map of
the product being built, the features that will be included, and
much more.
 Roadmap helps to keep the technical and non-technical team on
the same wavelength as to what the expectations are.
 Helps to ensure that the product is built meeting the needs
whether it’s for internal purposes, for users or clients.
 Serves as a contract between the customer and the developer.
 Serves as a source of test plans.
 Servesto specify project goals and plan development cycles and
increments.
The software requirements document
Characteristics of SRS
Complete
Consistent
Correct
Modifiable
Ordered
Testable
Traceable/ Visible
Unambiguous/clear
Valid
Verifiable
Users of a software requirements document
The software requirements document Structure
 Since the requirements document serves as a foundation for
subsequent software development phases, it is important to develop
the document in the prescribed manner. For this, certain guidelines
are followed while preparing SRS. These guidelines are listed below.
 Functionality: It should be separate from implementation.
 Analysis model: It should be developed according to the desired
behavior of a system. This should include data and functional response
of a system to various inputs given to it.
 Cognitive model: It should be developed independently of design or
implementation model. This model expresses a system as perceived by
the users.
 The content and structure of the specification: It should be flexible
enough to accommodate changes.
 Specification: It should be robust. That is, it should be tolerant
towards incompleteness and complexity.
Requirements document structure
Software Requirements Document Contents
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Intended Use
1.4 Scope
1.5 Definitions and Acronyms
2. Overall Description
2.1 User Needs
2.2 Assumptions and Dependencies
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Nonfunctional Requirements
 Requirements document structure
Software Requirements Document Contents
1. Introduction
1.1 Purpose: Set the expectations for the outcome of the product.
1.2 Intended Audience: Who is the software for? Who is the end-user? Will the software be used internally at a company or
externally?
1.3 Intended Use: What is the software for? What problem is it solving?
1.4 Scope: Explain the scope of the software. What are the main goals and objectives? How do they relate to the company’s goals?
1.5 Definitions and Acronyms: Provide an overview of any definitions the reader should understand before reading on.
2. Overall Description: Describe what you are building and for who.
2.1 User Needs: Explain the user needs for this software.
2.2 Assumptions and Dependencies: What assumptions are you making that could cause an error in your approach? Is the project
reliant on any other factors that could affect the development of the software?
3. System Features and Requirements
3.1 Functional Requirements: Take time to define the functional requirements that are essential for the software to build.
3.2 External Interface Requirements: Are there any UX and UI requirements that you must keep in mind as you build?
3.3 System Features: What features are required for the software to even work.
3.4 Nonfunctional Requirements: Are there any non-functional requirements that you need to address (i.e. budget, team, etc.)
The end!!!

91