REQUIREMENT ANALYSIS

AND SPECIFICATION
Sanjeev Sarma, Webx

1
Introduction
• Requirements Gatherings
– Goals and Challenges
– Standard Approaches
– Example Requirements List
– Documenting Operational Requirements
• Traditional Deliverables
– Requirements Specification Documents
– Analysis Diagrams:
• Context Diagram,
• Entity Relationship Diagram,
• Data/Control Flow Diagram
– Prototype

2
 Requirements Gathering

Analyzing Business Requirements

3
Goals of Requirements Gathering
 Find out what the users need
 Document needs in a Requirements
Specification
 Avoid premature design assumptions
 Resolve conflicting requirements
 Clarify ambiguous requirements
 Eliminate redundant requirements
 Discover incomplete or missing requirements
 Separate functional from nonfunctional
requirements
 Ensure Requirements Traceability
4
Requirement Specifications seldom clearly
capture customer needs

What user wanted   How customer described it How analyst specified it How designer implemented it

5
Challenges in Requirements Gathering
Consider a scenario illustrating the normal
state of flux:
Often you are using new business procedures,
and your job has changed to head development
of a brand new application your company has
announced, and you are scheduling training for
you and your team to master a new computer
environment and new software development
techniques and new tools using a new
programming
end users, language,
analysts, how dotraining
you staff
figure out
andcustomers,
documentdesigners,
how the new supportapplication
staff is
supposed to workimplementers,
marketing staff, in a way maintenance
that is clearly
staff,
understood by:
managers, testers, ...?

6
Standard Approaches for Requirements
Gathering
 Obtain requirements through user interviews
 Gathering representatives of stakeholders:
 Executives
 Developer
 Maintenance users
 support staff
 ...
in one room at during uninterrupted session(s) to decide on
requirements under an experienced leader/consensus
maker:
Joint requirements planning (JRP)
 focus on what the system will do

Joint application design (JAD)

 focus on how the system will work produce a document which
includes a list of requirements
 Developing a Rapid Prototype
7
Example Requirements List 1 (1 of 3)
Requirement Comments
The system will support client inquiries from 4 access Four access points are how; we
points: in person, paper-based mail, voice should focus on who needs
communication, and electronic communication access and from where
(Internet, dial-up, and LAN/WAN
The telephone system must be able to support an 800 Can't use 888 or 877? Missing
number system who needs what kind of access
from where
The telephone system must be able to handle 97,000 Valuable statistics. This
calls/yr. and must allow for a 15% annual growth. It is requirement is actually pretty
estimated that 19% of these calls will be responded to good.
in an automated manner and 81% will be routed to
call center staff for response. 50% of calls can be
processed without reference to the electronic copy of
the paper file, and approximately 50% will require
access to system files.
For the calls that require access to system "optical disk" is a design
information, response times for the electronic files assumption. Response times are
must be less than 20 seconds for the first image good non-functional
located on the optical disk, less than 3 seconds for requirements if not linked to
electronic images on a server, and less than 1 second design assumptions (hardware
for data files. device types).
8
Example Requirements List 1 (2 of 3)
Requirement Comments
The telephone system must be able to support voice Pretty good one. Can you find
recognition of menu selections, touch-tone menu anything wrong?
selections, and default to a human operator. The
telephone menu will sequence caller choices in order
of most frequently requested information to the least
requested
The telephone system must be able to provide a voice This seems to be trying to
response menu going from a general menu to a provide some pretty obvious
secondary menu. advice to a dumb designer
The system must allow for the caller to provide "Through a digital recording"?
address information through a digital recording and to This is a design assumption
indicate whether it is permanent.
The system must allow for the caller to provide Sound familiar? (It's redundant)
address information through voice recognition and to
indicate whether it is permanent.
The telephone system must be able to store and Simplify it: "The system must be
maintain processor IDs and personal identification able to identify callers and route
numbers to identify callers and to route calls properly calls to the appropriate internal
to the appropriate internal response telephone. response telephone".
The telephone system must be able to inform callers Great!
of the anticipated wait time based on the number of
calls, average duration of calls, and the number of
calls ahead of them.
9
Example Requirements List 1 (3 of 3)

Requirement Comments
The journal will contain entries for key events that This is a design for a journal.
have occurred within the administration of an Why have it? What is its
individual's account. The system will capture date, purpose?
processor ID, and key event description. The system
will store pointers to images that are associated with a
journal entry as well as key data system screens that
contain more information regarding the entry.
If an individual double-clicks on an event in a Double-click is a user interface
member's journal, the system will display the design assumption
electronic information and the images associated with
the event.
The system will restrict options on the information bar This one has many user interface
by processor function. When an icon is clicked, the design assumptions.
screen represented by the icon will be displayed and
the system will display appropriate participant
information.

Note: Each requirement should have a number to provide traceability.

10
Example Requirements List 2 (1 of 2)
Requirement Comments
6.7.1.2 The system Too vague. Implies fiscal year has some impact on how
must provide the customer transactions are organized, but does not specify what
capability to capture that is. Implies some data entry, but needs to be stated more
all of the customer specifically. May be trying to make a statement about volume,
transactions for fiscal meaning old transactions can't be archived until they are a year
6.7.1.3
year The system will Saying
old? "restricted" is OK, but details about the restriction (who
provide restricted can, who can't) should be stated clearly in this context. Also
remote inquiry access vague is the reference to remote inquiry. How remote? Saying
(via dial-in) to view "remote access" when referring to mobile employees working in
images and data the field but still within a couple of miles of the office or
separately or worldwide access. Can have huge implications on system.
6.7.1.4 The
simultaneouslysystem will Makes several technical design assumptions. Barcoding is a
barcode documents solution, not a requirement. This system probably needs a way
automatically prior to to identify each document uniquely, but it doesn't have to be
distribution. At a barcodes. If all existing systems use document barcoding (not
minimum, the codes the case with this system), should write a nonfunctional
will be used to identify requirements that states, "Unique identification of all documents
to which work queue will be done through barcoding". By specifying barcoding in the
the documents should functional specifications, changing to glyphs, optical character
be routed within the recognition (OCR) will be more difficult. The reference to queues
organization when they makes an assumption about a workflow-package-oriented
are returned system. Better to state: "At a minimum, the unique id will
ensure routing to a specific worker in the organization when
11
documents are returned."
Example Requirements List 2 (2 of 2)
Requirement
6.7.1.5 When a workflow is
initiated, the system must be
able to pre-fetch the documents
that are in electronic image
format by document type or
grouping of documents by
process
6.7.1.6 The system must create
an entry in the journal file
whenever a letter is created
6.7.1.7 System must maintain list
of current, open work processes
and identify work process to be
executed and workflow queue for
process. When documents are
scanned, system determines
whether there is a process open
for that SSN. If there is, the
system routes document to
appropriate workflow queue,
displays
12 work process script, and
highlight current work process.
Comments
Look at references to workflow. Requirements
document has specified a workflow solution! This
whole entry is suspicious. Seems to be saying that we
must cache documents by two different criteria: by
type or by process. Criteria are good requirements,
but caching (pre-fetching) is a solution to address
performance problems.
Assumes presence of a journal file containing entries
inserted when a letter is created. Seems focused on
front end ("do this") instead of back end ("in order to
get this"). Why put entries in a journal file? To create
a list of all letters created, when and by whom? This
would make a better, clearer requirement.
Seems to be focused on how rather than what.
Instead of specifying the steps a system must go
through, clearly document the end in mind. Example:
"When a new document image is brought into the
system, it should be routed to the worker who has the
account open for the same SSN as the new document
and should be made obvious to that worker. If no
worker has an open account, the document should be
made available to any worker."
Obtaining Operational Requirements
Problems with traditional ways of specifying
problems:
 customer may not adequately convey the needs of the user.
 developer may not be an expert in the application domain, which
inhibits communications.
 users and customers may not understand the requirements
produced by the developer
 developer's requirements specifications typically specifies system
attributes such as:
 Functions
 Design constraints
 Quality attributes
 System interfaces and
 Performance factors

but typically contains little or no information concerning

operational characteristics of the specified system.
13
Guidelines for Operational Concept
Document
Operational Concept Document (OCD) describes the
mission of the system, its operational and support
environments, and the functions and characteristics of the
computer system within an overall system.
Several guidelines and standards exist to prepare an OCD:
 Mil-Std 498 for Department of Defense SW development
 IEEE Standard 1498 for commercial SW
development,
 AIAA OCD 1992 for the American Inst. of Aeronautics
and Astronautics (for embedded real-time systems)
 ConOps 1997 Concept of Operations Document
Guidelines proposed by Fairley and Thayer [FT97]
because they felt the above guidelines were Systems-oriented
and developer-oriented instead of user-oriented.

14
The Concept of Operations Document
Identifies
 classes of users and
 modes of operation
 Normal mode
 Emergency mode
 Maintenance mode
 Backup mode
 Degraded mode
 Diagnostic mode
Users communicate
 essential needs
 desirable needs -- prioritized
 optional needs -- prioritized
Prioritized user needs provide the basis for
 establishing an incremental development process, and
 making trade-offs among operational needs, schedule and
budget.

15
Concept Analysis
Concept Analysis Team, include representatives from
 User organization
 Training
 Buyer organization
 Operational support
 Developer organization or Development Experts/Consultants
Results of concept analysis are recorded in the ConOps
document written in narrative prose using users' language,
and using visual forms (diagrams, illustrations, graphs, etc.)
wherever possible.
Each operational scenario needs a test scenario to validate
the system in user's environment. Validate proposed
system by walking thru all scenarios, include both normal
and abnormal operations:
 Exception handling
 Stress load handling,
 Handling incomplete data
 Handling incorrect data.
16
Outline for a Concept of Operations
Document
1 Scope 5 Concepts of Operations for the
1.1 Identification New or
Modified Proposed System
1.2 System Overview
5.1
Scope Background, Objectives &
1.3 Document Overview
2 Referenced Documents 5.2 Operational Policies &
Constraints
3 The Current System or Situation 5.3
3.1 Background, Objectives, & SystemDescription of Proposed
Scope 5.4 Modes of Operation
3.2 Operational Policies &
Constraints 5.5 User Classes
3.3 Description 5.5.1
Structures Organization
3.4 Modes of Operation 5.5.2 Profiles of
3.5 User Classes User Classes
3.5.1 Structure
Organizational among 5.5.3
User Classes Interactions
3.5.2 Profiles of 5.6 Other Involved Personnel
User Classes 5.7 Support Environment
3.5.3 Interactions 6 Proposed Operational Scenarios
Personnel3.5.4 Other Involved 7 Summary of Impacts
3.6 Support Environment 7.1 Operational Impacts
4 Justification
Proposed for and Nature of 7.2 Organizational Impacts
Changes & New Features
4.1 Justification 7.3 Impacts During
Developments
4.2 Description
4.3 Priorities among Changes/ 8 Analysis of Proposed System
Features
174.4 Changes/Features Considered 8.1 Summary of
but Improvements
Rapid Prototype

[www.dilbert.com ]

Having a prototype during requirements phase

gives you something to work from when
communicating with the users and client, and
results in a user-centered GUI design

18
Traditional Expressions of Functional
Requirements
 Requirements specifications
 Hard to read. Contract-like.
 Context Diagram
 Specifies users, software, hardware that interface with
system
 Data-flow Diagrams (DFD)
 Useful for technical people but tend to confuse users
 Useful in design of non-object-oriented systems
 Entity-relationship diagrams (ERD)
 Critical to database design but are not easily understood
by users
 Prototypes
 Good communication tool to obtain information from user.
 Great for proof-of-concept tasks.
19
 Useful in developing user interface designs.
 Unified Modeling Language

(UML)

20
UML Diagrams
 Instead of the Context, Data-Flow and
Entity-Relationship Diagrams used in
Structured Analysis, UML produces 9 types
of diagrams
 Use Case Diagram
 Sequence Diagram
 Collaboration Diagram
 State chart Diagram
 Activity Diagram
 Class Diagram
 Object Diagram
 Component Diagram
 Deployment Diagram
21
 Use Cases

22
History of Use Cases
 Ivar Jacobson and his team at Ericsson in Sweden
introduced Use Cases in their book:
 I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard.
Object-Oriented Software Engineering: A Use Case Driven
Approach, ACM Press, 1992.
 Use Cases were included as part of their overall
system development lifecycle methodology, called
Objectory, which was sold to Rational Software.
Now Use Cases are part of the Rational Unified
Process, created by the "three amigos":
 I. Jacobson, G. Booch and J. Rumbaugh. The Unified
Software Development Process, Addison-Wesley, 1999.

23
What is a Use Case?
 The Use Cases describe the behavior of a
system from a user's standpoint using
actions and reactions.
 The Use Case Diagram defines the
system's boundary, and the relationships
between the system and the environment:
 different human users roles interact with our
system
 other software systems/applications
 hardware systems/devices
 Use Cases support the specification phase
by providing a means of capturing and
documenting requirements
24
Use Case Deliverables
 There are two parts to document a use case:
 the use case diagram,
 provides visual overview of important interactions
 captures scope (identifies external entities)
 the use case itself
 documents in a textual form the details of the
requirements, what the use case must do.
 A use case is actually a page or two of text representing
each oval in the use case diagram
 A project should have a standard template for use
cases.

25
Use Case Diagram
actor system
Real Estate System

Buyer Sell Property

Seller

Advisor use case

interaction

26
Use Case Documentation Template
Use Case Number: A unique numeric identifier Use Case Name: A unique descriptive
identifier
Iteration: Facade (Outline and high-level description), Filled (Broader, deeper), Focused (Narrower),
Finished
Summary: Briefly state the purpose of the use case in one or two sentences to provide a high-level
definition of the functionality provided by the use case.
Basic Course of Events: 1. Include the following:
1. This is a numbered list. The use case number is 4.1 What interaction the use case has with
used togetherfor with this number to provide the actors
requirements traceability 4.2 What data is needed by the use case
2. Write this as a flow of events describin what the 4.3 When and how the use case starts and
ends
system should do, not how the system should do
4.4 The normal sequence of events for the
it. use case
3. Write it in the language of the domain, not 4.5 The description of alternate or
technical jargon exceptional flows,
Alternative Paths: What happens if ... invalid information is entered,
whatunusual types
happens if ...of processing occurs,
or uncommon conditions occur, how is the flow completed?
5. The description of each step grows in detail
Exception Paths: What happens if... an error occurs, how is asthe flow affected?
analysis progresses
Extension Points: Describes an <<extend>> relationship, shows steps which are extended by optional
steps in another case
Trigger: Describe entry criteria for use case, may describe business need, may be time-related, or
completion of other case
Assumptions: Critical section for project manager. Things (out of scope of system) you assume to be
true but might not be true
Preconditions: List things that must be in place before interaction can occur. (Part of contract between
use case & outside world.
Postconditions: List things that will be satisfied if use case is completed successfully. Independent of
alternative paths taken.
Related Business Rules: Written and unwritten company business rules that relate to requirements
presented in this use case
Author: This is placed at the bottom, together with the date to allow critical information to be speed
read
Date: Facade, Filled, Focused, Finished dates

27
Use Case Documentation Example
Use Case Number: 1 Use Case Name: Sell Property
Iteration: Filled (Four stages of iteration are Facade, Filled, Focused, and Finished)
Summary: System Context Use Case. The seller lists the property, a buyer purchases the property,
and the agent guides them through the process and offers advice, caution, and recommendations
Basic Course of Events: 9. System responds by notifying seller and
seller's agent
1. Seller selects an agent 10. Seller responds to the offer with a
2. System responds by assigning an agent and counteroffer.
notifying the seller's agent. 11. System responds by notifying buyer and
3. Seller lists the property to sell. buyer's agent.
4. System responds by displaying this property in 12. Buyer and seller agree to terms
the property listing and linking it for searches 13. System responds by recording the
5. Buyer selects an agent. agreement
6. Buyer reviews the property listings by entering 14. Buyer indicates a loan is required
search criteria 15. System responds by locating an appropriate
7. System displays properties matching buyer's loan provider
search criteria 16. Buyer and loan provider agree to loan terms.
8. Buyer finds a property and makes an offer on it. 17. System responds by recording terms of loan
Alternative Paths: N/A
Exception Paths: N/A 18. Buyer and seller close on property.
19. System responds by recording details of
Extension Points: N/A close.
Trigger: N/A
Assumptions: N/A
Preconditions: N/A
Postconditions: N/A
Related Business Rules: N/A
Author: Rumpel Stilskin
Date: March 10, 2001 – Facade; April 20, 2001 -- Filled
28
A Simpler Use Case Template
 A simpler template for Use Case
documentation is recommended by Terry
Quatrani [TQ98]
 For each use case:
X Flow of Events for the <name> Use
Case
X.1 Preconditions
X.2 Main Flow
X.3 Subflows (if applicable)
X.4 Alternative Flows
where X is a number from 1 to the number
of the use case
29
Associations in Use Case Diagram
 Associations can exist
 between an actor and a use case,
 between use cases, and
 between actors
 Types of Use Case Associations
 Communicates between actor and use case
 named or unnamed relationship showing participation of
actor in use case, use a solid line connecting actor to use
case
 Generalization between actors
 Adornments = Stereotyped Associations between use cases
 <<extend>>
indicates relationship between use cases in which a special
use case (the non-arrow end) extends an original use case
(the arrow end)
 <<include>>
reuses steps in a use case instead of cut-and-pasting steps
into multiple use case documents, by pulling out common
steps into a new use case and specifying with an arrowed
line the <<include>> association between this new use
case and those use cases requiring the steps
 <<uses>>
An instance
described byofthe
thetarget
source use case includes behavior
30 Shows a stereotyped generalization relationship between
use cases
Example of Generalization between Use
Case Actors

Service Representative

Customer Service Representative Field Service Representative

31
Example of Communicates Use Case
Relationship

Sell Property

Buyer

Triggers
Sell Property

Buyer

32
Example <<uses>> and <<extends>> Use Case
Relationships

Transfer by computer

Remote Customer Local Customer

<<extends>>

Transfer

<<uses>>

Identification

33
Example <<include>> and <<extends>> Use Case
Relationships

Schedule Customer
Appointment

Office Administrator <<extends>>

<<includes>>

Schedule Recurring
Schedule Designer Customer Appointment

<<includes>>

Enter Customer Order

34
 The Use Case View for the
Case Study:
Course Registration System

35
The Actors
 In the Course Registration System,
answering the questions suggested to find
actors yields:
 Students want to register for courses
 Professors want to select courses to teach
 Registrar must create the curriculum and generate a
catalog for the semester
 Registrar must maintain all the information about courses,
professors, and students
 Billing System must receive billing information from the
system
 Actors identified from above:
 Student – person registered/registering in classes at the
University
 Professor – person certified to teach classes at the
University
36
 Registrar – person who maintains the Course
The Use Cases
 Answering the questions to find use cases
yields:
 The Student actor needs to use the system to register for
courses
 After the course selection process is completed, the Billing
System must be supplied with billing information
 The Professor actor needs to use the system to select the
courses to teach for a semester, and must be able to receive a
course roster from the system
 The registrar is responsible for the generation of the course
catalog for a semester, and for the maintenance of all
information about the curriculum, the students, and the
professors needed by the system
 Based on the needs, the following cases are identified:
1. Register for courses
2. Select courses to teach
3. Request course roster
4. Maintain course information
5. Maintain professor information
6. Maintain student information
37
7. Create course catalog
The Flow of Events (1 of 3)

38
The Flow of Events (2 of 3)

39
The Flow of Events (3 of 3)

40
Use Case Diagram (1 of 2)

41
Use Case Diagram (2 of 2)

42
Select a Use Case and Sub-Flow
 Look at a use case: Select Courses to Teach
 Select a subflow: Add a Course Offering
 Although the flow is written sequentially, in the real world many
steps may occur concurrently
The professor logs onto the Registration System and enters password.
The system verifies the password is valid (E1) and prompts the
professor to select the current semester or a future semester (E2).
The professor enters the desired semester. The system prompts the
professor to select the desired activity: ADD, DELETE, REVIEW, PRINT,
or QUIT. The professor chooses ADD, the S-1: Add a Course Offering
subflow is selected.
S-1 Add a Course Offering
The system displays the course screen containing a field for a course
name and number. The professor enters the name and number of a
course (E-3). The system displays the course offerings for the entered
course (E-4). The professor selects a course offering. The system links
the professor to the selected course offering (E-5). The use case then
begins again.
E-3: An invalid course name/number is entered. The user can re-enter
a valid name/number combination or terminate the use case
E-4: Course offerings cannot be displayed. The user is informed that
this option is not available at the current time. The use case begins
again.
E-5: A link between the professor and the course offering cannot be
created. The information is saved and the system will create the link
43
at a later time. The use case continues
 Case Studies

44
 Thank You

45