Session 3 - Defining Software Requirements

Software Project Management Session 3: Defining Software Requirements
Day 3 Topics
• Difficulties in gathering software requirements
• What makes a good requirement?

• Gathering the Business Requirements
• Gathering the Functional

Requirements
• Gathering the Technical

Requirements
• Requirements Management
using a Traceability Matrix
This session presents an overview of the software requirements process with an

emphasis on the importance of documenting software requirements and the tools
and general activities that must be performed. It does not cover the details of how
to create requirements documentation --- this is left to more specific software
engineering classes.
This session addresses the following objectives:
• Describe levels of software requirements and list appropriate techniques for
gathering them.
• Practice using tools for collecting and documenting levels of business
requirements
• Create a preliminary Requirements Traceability Matrix as a base for
managing requirements throughout the project.
Software Requirements
The First Step
This key step is too often neglected or performed in a perfunctory manner. It

requires that the project team spend more time studying the business world and less
time with the technology --- and most software professionals would rather be
writing and testing code. However, every system of any size needs clearly
documented requirements. Without good requirements, project risks increase
dramatically ---- in particular risks related to increased schedule as a result of
rework or creeping scope.
Collecting Requirements
What customers
want and do ask
What for
customers
want but
don't ask for
What
customers
ask for
What
What customers don't
customers want but
want/need do ask for
The goal of the project is to deliver what the customers need. Thus the goal of
the requirements process is to make "What customers ask for" as close as
possible to "What customers want and need." Each step of the requirements
gathering process refines the project teams' knowledge so that they ask the
right questions and listen to the answers.
Defining the requirements for a product is a process of exploration and
refinement. Each step produces a better approximation of what the customers
really want. However, it is an almost impossible task to completely identify
all requirements. The project team's task is to get as close as possible in order
to create a product that comes close to satisfying all the key requirements.
It is the nature of technical projects that the problem and the solution are
complex and intertwined. As the solution emerges, the requirements are
clarified and often change.
The specific information gathered for requirements can vary dramatically with
the project type. For example, requirements documentation for connectivity
in an office move includes a server names, connectivity maps, and circuit
capacity. The requirements documentation for an information system
application would include business areas affected, user scenarios, data for
reports, etc. In both cases, this is the information needed to design the
solution.
Requirements Difficulties
• Missing information
• Ambiguous words
• Extraneous elements
• Different interpretations
• Locking onto an implementation too early
• Analysis paralysis
NOTES:
Incomplete and ambiguous requirements are a major source of software project
problems. Sources of requirements ambiguities include:
• Unclear and incomplete problem statements
• Ambiguous wording
• Unclear context
• Human error
- Observational errors
- Recall errors
- Interpretation
• Rushing to a solution
• Assumptions
A good requirements process gathers just enough information of the appropriate type
at each point in the process.
According to Barry Boehm, in "Software Engineering Economics," the relative cost
to fix an error grows from a value of 1 at Requirements to from 40 - 1000 in
Operation. It makes good business sense to do a good job of collecting and verifying
requirements early.
Requirements Documentation
NOTES:
Why create written requirements documentation?
• Written documentation extends what the mind can grasp and remember;
• It gives the same story to all team members;
• It provides information for new members who join the project; and,
• It helps the writer to better understand the problem.
Requirements documentation should address:

• Functionality. What is the solution supposed to do?
• External interfaces. How does the solution interact with people? With
hardware? With software?
• Performance. What is the speed, availability, response time, recovery time of
the various functions?
• Attributes. What are the considerations around portability, correctness,
maintainability, security, etc.?
• Design constraints imposed on an implementation. Are there any required
standards in effect, implementation policies, resource limits, etc.?
Requirements documentation should not:

• Specify the design of the solution; and,
• State specific project management requirements.
Considerations For Creating Good Requirements Documentation

(adapted/rom IEEE Std. 830-1998)
Requirements are:
Correct if every requirement stated is one that the solution shall meet. The customer or user
determines if the requirements correctly reflect the actual needs. Traceability makes this
procedure easier and less prone to error.
Unambiguous if every requirement stated has only one interpretation.
Complete if they include all significant requirements, whether relating to functionality,
performance, design constraints, attributes, or external interfaces. The requirements also
must define the responses of the solution to all realizable classes of situations and both
valid and invalid input values, as well as include definitions of all terms.
Consistent if the documentation is internally consistent -- that is no subset of individual
requirements described is in conflict.
Prioritized if each requirement stated is ranked according to importance and stability.
Verifiable if for each requirement stated, there exists some finite cost-effective process with
which a person or machine can check that the solution meets the requirement. In general
any ambiguous requirement is not verifiable.
Modifiable if its structure and ~tyle are such that any changes to the requirements can be
made easily, completely, and consistently while retaining the structure and style.
Modifiability generally requires that the documentation has a coherent and easy-to-use
organization with a table of contents, an index, and explicit cross-referencing. In
addition, Each requirement should be stated separately and should not appear in more
than one place in the documentation.
Traceable if the origin of each of the stated requirements is clear and if it facilitates the
referencing of each requirement in future development documentation. Backward
traceability means that each requirement explicitly mentions its source in earlier
documents. Forward traceability means that each requirement can be located in the
documents that follow.
Benefits of Good Documentation

• Clear expectations of what the project is to
produce
• Agreement between the project team,
the customers, and the stakeholders
• Reduced re-work
• Baseline for managing project
change
• Improved communication
Two of the Standish Group "CHAOS Ten" factors have to do with good
documentation of business objectives and clear requirements. Appropriate
requirements documentation provides several specific benefits:
• Establishes the basis for agreement between the customers and the suppliers
on what the solution is to do.
• Reduces the development effort. The requirements process ensures that the
various concerned groups in the customer's organization consider
rigorously all of the requirements before design begins, thus reducing later
re-work and re-testing.
• Reveals omissions, misunderstandings, and inconsistencies early in the
development cycle when these problems are easier to correct.
• Provides a basis for estimating costs and schedules. The description of the
solution to be developed is a realistic basis for estimating project costs and
schedules.
• Provides a baseline for validation and verification. The requirements
provide a baseline against which project success can be measured.
• Serves as a basis for enhancement. The requirements documentation serves
as a basis for later enhancements to the finished solution.
Software Project Management Session 3: Defining Sr;JftwareRequirements
Requirements and Communication
• The requirements process requires excellent

team and customer communication
• As team understanding and communication
improve, the teamwork builds
• Corollary: Keep the requirements team
involved for the duration of the project
According to Gerald Weinberg in "Exploring Requirements," the "requirements

process is the part of development in which people attempt to discover what is
desired."
Consequently, the process of developing requirements is actually a process of
developing a team of people who:
• Understand the what is desired;
• Stay together to work on the project; and,
• Know how to work effectively as a team.
This team building aspect of the requirements process isjust as important as
the written requirements documentation which is produced.
Levels of Requirements
~ Business objectives & areas

~ Stakeholder success criteria
~ Architectural Direction
• Functional
~ Business Functions/Scenarios
~ Implementation attributes
~ Requirements Traceability
• Technical
~ Specific solution component
requirements
The requirements process is one of step-wise refinement. It starts with

conceptual information about the business process and continues to refine this
information until a technical solution can be designed to address the original
problem. Some of this conceptual information is gathered during the initiation
and justification for the project.
When the project is approved, "Business Requirements" are collected to further
define the project context in terms of the business and to clarify what the
customers expect. The next step, "Functional Requirements" identifies what
business processes are supported, and establishes the business features that the
solution should support. The last step, "Technical Requirements" specifies what
the technology must do to support these features.
Tools for Business Requirements
• User Interviews
• Business Context Diagrams
• System Context Diagrams
The business requirements establish a firm foundation in the current and proposed
business process and the overall architecture of the solution. Business
requirements build on the analysis performed as part of a market analysis or
feasibility study in addition to the Problem/Opportunity analysis performed for
the Project Charter.
User interviews at many levels are required to capture and understand the business
requirements. Executive interviews help to establish the overall interactions.
Interviews with middle managers and end users present the detailed view of the
business requirements.
Business requirements are often best expressed using graphical tools that present a
"birds-eye" view of the process. Business Context diagrams present such a view
of the business interactions. System Context diagrams present a "birds-eye" view
of the system interactions.
Business-requirements must be presented in the language of the end user, avoiding
use of technical terms. The purpose of gathering business requirements is to gain
a thorough enough understanding of the problem/opportunity and the business
area to assist the users in specifying the functional and technical requirements for
the most appropriate technology solution.
Business requirements describe what the users need to do to perform the tasks
which will ultimately be automated or supported by the information technology.
Context-free Questions*
Context free questions are posed early in the project to obtain information about global properties
of the problem and potential solutions. Many of these questions may have been asked as part of
the ITB Project Initiation phase. However, they may also be appropriate for interviews at the
beginning of the approach phase. Context -free questions apply no matter what the solution is to
be. In terms of project decisions, these questions help ensure that we are on the right limb instead
of "out on a limb."
Clearly determining the context early in the process helps avoid hearing this:" Oh, we thought
you knew that. We always do it that way!"
The answers to the process questions help determine the approach and who is involved in the
project. The answers to the product questions help establish boundary conditions for the
requirements. The meta questions help understand the value of the interview and may uncover
hidden problems early in the project.
Process Questions
Who is the customer?
What is a highly successful solution really worth to this client?
What is the real reason for wanting to solve this problem?
Should we use a single design team, or more thim one?
Who should be on the team(s)?
How much time do we have for this project?
What are the tradeoffs?
Where else can the solution to this problem be obtained?
Can we copy something that already exists?
Product questions
What problems does this product solve?
What problems could this product create?
What environment is this product likely to encounter?
What kind of precision is required or desired in this product?
Meta questions
Am I asking you too many questions?
Do my questions seem relevant?
Are you the right person to answer these questions?
Are your answers official?
*Adapted from "Exploring Requirements" by Donald Gause & Gerald Weinberg
Business Context Diagrams

• Present a high level graphic of the business
entities and their interactions
• Are a valuable interviewing tool
• Help clarify the problem! opportunity and
define scope
• Use to show differences between current and
proposed situations
A Business Context diagram is a useful and quick tool to describe user

interactions in the business environment. Use the this tool in the early stages of
gathering business requirements.
It is often helpful to diagram each area of the business separately to gain a
thorough understanding of the transactions in each area. These diagrams can then
be combined to create an overall view.
It is relatively easy to sketch a Business Context diagram as part of an interview:
• First list the key user classes involved;
• Draw and label a bubble for each entity/user class;
• For each general interaction between user classes, draw and label an arrow
showing the direction of the interaction; and,
• Collect the user class and interaction definitions for entry into the project
glossary.
Service Request Current Situation
Assignments
"'''T
comPleled~Mana~:ment
Request for
Priority
SERVICE REQUEST CURRENT SITUATION

CONTEXT DIAGRAM
09/15199
Business Context diagrams can be used to show the current and proposed
interactions at a conceptual level. The difference between the two diagrams shows
the business structure changes that will occur as a result of the software project.
In the Service Request example shown, there is no Help Desk in the current
situation. The Help Desk appears in the proposed solution diagram, showing that
this new function will need to be added to the organization.
Service Request Proposed Situation

Service Request
Status
~-"'
IMana~menll
" ,/
SERVICE REQUESTI HELP DESK

PROPOSED SITUATION
CONTEXT DIAGRAM
09115199
The proposed solution also shows a potential Expert System, the result of the
software project.
Systems Context Diagram Example
OPERATIONS BRANCH
FIS REDESIGN PROJECT
CONTEXT DIAGRAM
REQUESTED
~ REPORT
TIME REPORTING
FIELD • ~ PARAMETERS
INFORMATION
DIVISIONS
!l~A"O'
REQUESTE~
AND FIELD REPORT
PERSONNEL
OFFICES PARAMETERS
TIME REPORTING
INFORMATION
~
UI
WORKLOAD INFORMATION ~
REQUESTED
REPORT
PARAMETERS
BUDGET
ALLOCATIONS EMPLOYEE TIME
TABLE TIME REPORTING
MAINTENANCE REPORTING INFORMATION
INFORMATION INFORMATION
TIME DISTRIBUTION·
PERSONNEL
INFORMATION SYSTEM INFORMATION
REQUESTED EMPLOYEE SALARY & ""'-

REPORT ADDRESS INFORMATION ~
PARAMETERS
This tool shows the existing system and the user interactions with the system, as opposed to the
Business Context diagram which presents a bigger picture view of user interactions with each
other. System context diagrams are useful when the project is replacing or interacting with an
existing information system. Business context diagrams are appropriate when the project is
automating a function which did not exist or had no automation support.
Functional Requirements Tools
• Work Flow Diagrams

• Use Case Scenarios
• Implementation Checklists
~.~)
ff·
k/
jJ''!h
tf:
Functional requirements contain more detail about how the desired business
process will operate and specifics about what the solution needs to do in order to
support these business processes.
Functional requirements should maintain independence from the solution
implementation. For example, if the system requires secure access to data, then
this requirement is stated in terms of what user classes require access to what data -
- not in terms of what mechanism will be provided to ensure secure access. The
technical requirements and design will define the implementation that meets the
secure data access needs.
(wor~n~ diagrams clarify the details of the business process or <?.fthe ~yslem _
~teractions:-They show the processes and decisions that are required to
accomplish the interactions identified in the Business Context diagrams. Use Case
Scenarios use a standard format to describe the interactions between the users and
the system. The Implementation Checklist ensures that implementation concerns
are not overlOOked)
The Functional Requirements result in a list that includes specific actions that the
system must perform as well as attributes that the system implementation must
possess in order to operate successfully. Examples of such attributes include
response time, data volume, data security, and screen resolution .
.Functional requirements do not specify the exact solution --- they establish
parameters to make sure that the right solution is selected.
Work Flow Diagrams
• Represent the time-based flow of processes

• Clarify which processes are in scope and what
inputs and outputs are required
• Can help identify bottlenecks in the business
processes
A Work Flow diagram can be created directly from a Business Context diagram by
picking a starting point and tracing interactions until all the interactions are
accounted for. Use the following guidelines to create Work Flow diagrams:
• Each column on the Work Flow represents an entity or a user class
identified in the Business Context.
• Each block represents a process owned by the entity in which column it
appears.
• Each diamond represents a decision point, which is the responsibility of the
entity in which column it appears.
• The arrows show flow between the processes. Time progresses from left to
right.
• The diagram should show a continuous work flow from the first transaction
to one or more possible resolutions for the process selected.
• A given Business Context diagram can generate several Work Flow
Diagrams.
Example Work Flow Diagram for the Proposed Service

Request Process
SERVICE
REQUEST
TEAM LEADER
Note: Customer Contact may

occur In all shaded processes.
In any of these processes, the
"S representative and the
customer may agreG to cancel
the Service Request.
Work Flow Diagram for

IT Service Request Process
This Work Flow diagram shows the detailed interactions between the Help Desk Staff and the Second
Level Support staff who become involved when the Help Desk Staff can't resolve the problem
immediately.
Use Case Scenarios

• Provide a user-centric
view of the system
• Are based on the
business processes
identified in the
workflow analysis
• Are collected directly from representatives of
the various user classes in the system
• Serve as a continuing tool for tracking system
requirements to the business processes
A use case scenario describes a sequence of interactions between the system and an
external actor, and results in the actor accomplishing some task that is part of the
busi~es~ process workflo~. (!he ~ctor can b~ a person, another software
applIcatIOn, or another entIty fhat mteracts WIth the system.
Use cases focus the requirements search on asking the users what they need to do
with the system. According to Karl Weigers in his textbook, "Software
Requirements," this is more effective than the traditional approach of asking users
what they want the system to do for them. It focuses the users' attention on their
actions rather than on the system actions.
Use case modeling is used extensively in object-oriented approaches to software
development. However, this technique can be adapted and used with any software
development approach.
A typical use case scenario contains the topics identified in the following Use Case
Scenario template.
. USE CASE DIAGR.A1I •.I: CREDIT CJ.\RD PR.OCESSING
This example was downloaded from www.smartdraw.com/resources/examples/software.This website

is an excellent source for examples of different types of software diagrams.
USE CASE SCENARIO:

-----------------
Primary Actor:
Secondary Actors:
Software Project Management Session 3: Defining Software RequiremenJs
~L</vrJJJ .
l'l
Implementation Constraints Checklist /1
• Identifies requirements for physical attributes

• Helps to ensure that implementation
constraints are not missed
The Implementation Constraints checklist helps to identify restrictions on the

solution resulting from the need to meet specific values of attributes such as
response time, or volume of data. Examples of implementation constraints that
become requirements are:
~~ ~. The system must run on the existing network.
-..? \. The system must be available 7 days a week, 24 hours a day.
~ ,,'. The system must provide a response to queries within 2 seconds.
~7· l
Given three days of system training, users must be able to access 90% of the
system features.
\. The system requires a secure user log-in that limits capabilities depending
on the user profile.
i
I. • Navigation through the system screens should require no more than three
"- mouse clicks to reach an input screen.
Implementation constraints should be identified in the context of the business

related functional requirements. This means that the project team should focus first
on understanding the business results and second on identifying implementation
constraints. Since a team may be more familiar with the technology than with the
business area, too often the tendency is to focus on the constraints rather than the
business, resulting in a product that is over constrained and underspecified. Beware
of adding constraints that are really design decisions.
1. USAGE ENVIRONMENT
User constraints
• Computer literacy
• Frequency of use
• Training requirements
• Impact of change on business processes
Operations constraints
• System administrator
• Hours of availability
• Training requirements
Usage medium
• Web-based
• Hard copy
• Graphics
• Interactive displays
• Data transmission and interfaces
Response time
• User maximum wait time
• System timing interactions
• Batch system timing
Frequency of use
• Continuous
• Intermittent
Currency of data
• Is immediate update necessary?
• How "old" can the data be and still be useful?
--
Volume
• How many transactions of each type?
• How much data in each?
• What is the distribution of transactions? Any spikes?
• How many simultaneous users?
• How long must data be available?
• Is data archiving necessary?
• Should transactions be batched for processing?
Development and testing environment hardware

Existing hardware for implementation
Existing hardware interfaces
Existing directives that limit hardware possibilities
Existing databases and software interfaces

Existing implementation software
Existing directives that limit implementation software choices
Requirements for project support software
Development and testing environment software
Location of users, data, hardware, networks

Existing communication protocols
Printer, terminal, and ports required
System access limitations

Data access limitations
Sensitivity of data
Multi-level security requirements
6. RELIABILITY
Up-time requirements
Maximum recovery time allowed
Fault tolerance and failure logging requirements
__ Requirement for reconstructing all transactions

__ U ser accountability requirements
Need for frequent enhancements

Anticipated changes in related operations
Future projects that may affect this project
Constraints imposed by long range business plans

Impact on future projects
Session 3: Defining Software Requirements
-Software Project Management
Technical Requirements
• Entity Relationship Diagrams

• Object Diagrams
• System Interface diagrams
• Input and Output Screen Prototypes
• Navigation Prototypes
• Sample Reports
• Implementation Checklists
Technical requirements begin to identify the components of the solution in terms

of the features and characteristics that address the functional requirements. This
information rounds out the requirements, providing sufficient detail to begin the
design of the solution. In fact, some Software Development Life Cycle (SDLC)
approaches refer to this step as "High Level Design."
Entity Relationship diagrams at this point present key data structure and
relationship requirements. Object models, used in Object-oriented approaches,
show the relationships between the system components. System interface
diagrams identify physical interface requirements that the solution must meet.
Technical requirements also include models of the system in order to specify

customer interface needs and gain customer feedback on what the system will
look like. For example system prototypes are especially useful for previewing
the Graphic User Interface (GUI), general screen layouts, reports, or navigation
charts. The Implementation checklist is also used in gathering technical
requirements in order to identify requirements specific to a particular component,
e.g. the user interface or required bandwidth or speed of the specific components.
,,---
Example Entity Relationship Diagram (ERD)
Entities
Entities are represented by rectangles. An entity is an object or concept about which
you want to store information.
Attributes
Attributes are represented by ellipses. An Attribute describes properties or
characteristics of an entity.
Relationships
Relationships are represented by diamonds. A Relationship illustrates how two entities
share information in the database structure.
Cardinality
Cardinality specifies how many instances of an entity relate to one instance of another
entity.
This example, along with other ERD and software diagram examples, can be found on
www.smartdraw.com/resources/ examp les/ software.
Example Object Model: Class Diagram

Cl.d~'iJ2L~_G~\M : ELECTRO"<tc SI lOP!'):"\, C \R r
il~~~',-
SlbTotal:MOlley
sUsT~y
toto1-_
plonOolnO
"""""'"'0
1
s+t:tf~~;l~~~
10•• "
N"""
Expira~te
{clIdil1tdbc_ pell
••• s1I)ppq;cu1ob)tCIMfOIlly
••• lltcwditcWtcSOCiatedwtthil.
',. credit~D'Upm1'Cbe
thafpttr~~Omen(C
to let lbtal&bull ,t<m
CC'li~eloacW1th
·~n1lt'Ul1tClI!lIer~D..
-""""
P,rlJtlit:M<mey
tdciltemO
JaIOWltmO
The object class diagram is used to describe the static structure of a system in terms
of objects and their relationship to each other. Each object is shown with an Object
Name, the data attributes associated with that object, and the procedures that that
object can perform.
Example Object Architecture Diagram
This example shows the interfaces and inheritances between the major components
of a system that includes a web browser front-end and several databases.
Additional detail is added during design to create an object model.
Example Navigation Diagram
This example diagram shows the relationships between screens. It is used to design
the menus and navigation elements.
Example Web Interface
Customer Survey
Questions - Part II
PIQ~5e enter any comment5

you may have conceming
your i!ihopping experience
with us:
8. Question?
r Answer
(;7 Answer
2. Ql.uestion?
il
3. Question?
r Ans"".r
(e' Answer
10. Question?
rAn" .•.", f.' Answer
r Answer r Answer r Answer
r Answer
11. Question?
4. Question? r Answer
r Answer r Answer r Ans,,",lIlr
j;7 Ans ••• r r Answe. Ii' Ans ••••
er
5. Question? r Answer
S ;;J "'Special Pl"'Onlotions:

U
R 6. Question?
r Promotion 1 • Sign up!
V (' Answer r Promotion 2 - Sign up!
r Answer r Promotion 3 • Sign up!
t' Answer r' Promotion 4 • Sign up!
This web interface mock-up shows users the interface used to collect survey
answers.
Example Input Screen Prototype
Example input screens, query screens, and reports are essential for presenting the
technical requirements for end user approval. These screens and reports help to
identify the data which must be kept in the system and clarify how it will be
presented. This information is used to create the data model for the system.
This is an example input screen from the Help Desk/Service Request project.
Example Query Screen Prototype

~'\~.ilIIli:&"'ii'2X;;liiJjj
~;-Sellrdl Clni""Qfj( SSNJeot. Jl_lJt.I-lI~_iJ~ ,_ _ _ . _ ~- . 001l: 'I ~I!YISS2 ,~__3·
(;u,i"~~I:;:;.:::::'::.m:.~~=:~~w:::__.::=:~:=:::=::::_~:::··-r·-·::.
Find Claimom
Find Chum
FuuJ Rln.'JlnllnJ
f'lmJilnr:uw·~:
Verity OQr.:tOf
;.··MyWf1rk
Jo.ebV6 Cttllifft&;
~pt\. •• Ir.
Whd.IJMrtll
f.~ceptlol'l'
fl~~
~.;.'Uru'&$ig~8d Work
PendinQ C1oimt:
AfIJlI!ftb
Y/tllluUtll1
ExceptiollS
f\eviBWfi
Report$
MnQ.1'lIJI~ml~nl
Hdll
This example query screen shows a data area as well as navigation elements
including menus and tabs.
Requirements Traceability Matrix

• Prioritized list of all requirements
• Created as requirements are identified
• Shows backward referencing to
Business Requirements
• Shows dependencies between requirements
• Includes space for forward referencing
to module design and test cases
• Will be revised as the project progresses
The Requirements Traceability Matrix is a linked list that tracks all logical and
physical requirements back to the business need and forward to the module
design and test cases. It performs several functions as the project proceeds. The
Requirements Traceability Matrix:
• Ensures that when requirements change, their related requirements can be
investigated to see if they are affected and also need changing;
• Ensures that the solution is based on what was required, and that what is
designed can be traced back to overall objectives and specific
requirements, and,
• Is used by project management, vendors, designers, developers,
acceptance testers and business owners to verify that the requirements are
met.
" Software Project Management Session 3: Defining Software Requirements
Requirements Traceability Matrix Contents
For each requirement:

Requirement Number
Name/Description
Source
Priority
Dependencies
System Module( s)--TBD
Test Case Number(s)--TBD
The Requirements Traceability Matrix tracks key requirements throughout the

project life cycle. Information for each requirement includes the operational
scenario that drives the requirement. Also included is the priority (Essential,
Desirable, Optional) for use in making scope decisions if necessary.
Dependencies include those requirements upon which the given requirement

depends as well as those that are dependent on the given requirement.
The system modules that fulfill the requirement are identified during the Design
phase and are completed at that time, as are the specific test cases that validate the
required feature.
The Requirements Traceability Matrix is initialized at the beginning of the

Requirements phase and is added to as new requirements are identified.
Requirements Traceability Matrix

The Requirements Traceability Matrix creates a cross referenced list of all logical and physical
requirements. It identifies dependencies between these requirements, traces each one to an operational
scenario, and initializes a table that will be used for forward traceability into the design and test phases.
Nmbr Name/Description Use Case Priority Dependencies Design Test

Scenario Depends on Essential For Module Cases
[Briefly describe the requirement] [State the Use [Choose [List the [List the TBD TBD
Case Scenario one: requirement requirement
numbe that Essential, numbers that numbers that
drives this Desirable, must be are supported
requirement] Optional] included to
bYth:~
\. support this require '\t1
V7Y I,
, reQuirementl
I
1.
\t(9i~\
2.
3.
4.
5.
,---.
----------------------------------------
Requirements Documentation Components
• Business Requirements
• Functional Requirements
~ Logical Requirements
~ Physical Constraints
• Technical Requirements
• Requirements Traceability Matrix
The NASA Software Engineering Lab (SEL) website, http://sel.gsfc.nasa.gov, contains

excellent examples and templates for the following:
• Operations Concept Document - business requirements, operational
concept, and requirements traceability matrix
• Requirements and Functional Specifications - functional requirements
• Requirements Analysis Report - Summary and technical requirements
including data flow or object-oriented diagrams
IEEE standards for requirements documentation include the following:

• IEEE Std 1233 1998 - Guide for Developing System Requirements
Specifications
• IEEE Std 830 1998 - Recommended Practice for Software Requirements
Specifications
• IEEE Std 1362 1998 - Guide for Information Technology system Definition
- Concept of Operations Document
The IEEE website is http://www.ieee.com.
Session Three Review Questions

• What makes gathering requirements difficult?
• What are the levels of requirements and how

do they relate to each other?
• What tools would you use to gather and

document Business Requirements?

document Functional Requirements?
document Technical Requirements?
• What is the purpose of a Requirements Traceability
Matrix?

Session 3 - Defining Software Requirements

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Session 3 - Defining Software Requirements

Загружено:

Авторское право:

Доступные форматы

Software Project Management Session 3: Defining Software Requirements

• What makes a good requirement?

• Gathering the Functional

• Gathering the Technical

This session presents an overview of the software requirements process with an

This key step is too often neglected or performed in a perfunctory manner. It

Requirements documentation should address:

Requirements documentation should not:

Considerations For Creating Good Requirements Documentation

Benefits of Good Documentation

Requirements and Communication

• The requirements process requires excellent

According to Gerald Weinberg in "Exploring Requirements," the "requirements

~ Business objectives & areas

The requirements process is one of step-wise refinement. It starts with

Tools for Business Requirements

Business Context Diagrams

A Business Context diagram is a useful and quick tool to describe user

Service Request Current Situation

SERVICE REQUEST CURRENT SITUATION

Service Request Proposed Situation

SERVICE REQUESTI HELP DESK

Systems Context Diagram Example

REQUESTED EMPLOYEE SALARY & ""'-

Functional Requirements Tools

• Work Flow Diagrams

Work Flow Diagrams

• Represent the time-based flow of processes

Example Work Flow Diagram for the Proposed Service

Note: Customer Contact may

Work Flow Diagram for

Use Case Scenarios

. USE CASE DIAGR.A1I •.I: CREDIT CJ.\RD PR.OCESSING

This example was downloaded from www.smartdraw.com/resources/examples/software.This website

USE CASE SCENARIO:

• Identifies requirements for physical attributes

The Implementation Constraints checklist helps to identify restrictions on the

Implementation constraints should be identified in the context of the business

Development and testing environment hardware

Existing databases and software interfaces

Location of users, data, hardware, networks

System access limitations

__ Requirement for reconstructing all transactions

Need for frequent enhancements

Constraints imposed by long range business plans

• Entity Relationship Diagrams

Technical requirements begin to identify the components of the solution in terms

Technical requirements also include models of the system in order to specify

Example Entity Relationship Diagram (ERD)

Example Object Model: Class Diagram

Example Object Architecture Diagram

Example Navigation Diagram

Example Web Interface

PIQ~5e enter any comment5

S ;;J "'Special Pl"'Onlotions:

Example Input Screen Prototype

Example Query Screen Prototype

Requirements Traceability Matrix

Requirements Traceability Matrix Contents

For each requirement:

The Requirements Traceability Matrix tracks key requirements throughout the

Dependencies include those requirements upon which the given requirement

The Requirements Traceability Matrix is initialized at the beginning of the