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 FunctionalRequirements

• Gathering the TechnicalRequirements

• Requirements Managementusing a Traceability Matrix

This session presents an overview of the software requirements process with anemphasis on the importance of documenting software requirements and the toolsand general activities that must be performed. It does not cover the details of howto create requirements documentation --- this is left to more specific softwareengineering classes.

This session addresses the following objectives:

• Describe levels of software requirements and list appropriate techniques forgathering them.

• Practice using tools for collecting and documenting levels of businessrequirements

• Create a preliminary Requirements Traceability Matrix as a base formanaging requirements throughout the project.


Software RequirementsThe First Step

This key step is too often neglected or performed in a perfunctory manner. Itrequires that the project team spend more time studying the business world and lesstime with the technology --- and most software professionals would rather bewriting and testing code. However, every system of any size needs clearlydocumented requirements. Without good requirements, project risks increasedramatically ---- in particular risks related to increased schedule as a result ofrework or creeping scope.


Collecting Requirements

Whatcustomerswant butdon't ask for

What customerswant and do askfor

Whatcustomersask for

Whatcustomerswant/need

What customers don'twant butdo ask for

The goal of the project is to deliver what the customers need. Thus the goal ofthe requirements process is to make "What customers ask for" as close aspossible to "What customers want and need." Each step of the requirementsgathering process refines the project teams' knowledge so that they ask theright questions and listen to the answers.

Defining the requirements for a product is a process of exploration andrefinement. Each step produces a better approximation of what the customersreally want. However, it is an almost impossible task to completely identifyall requirements. The project team's task is to get as close as possible in orderto 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 arecomplex and intertwined. As the solution emerges, the requirements areclarified and often change.

The specific information gathered for requirements can vary dramatically withthe project type. For example, requirements documentation for connectivityin an office move includes a server names, connectivity maps, and circuitcapacity. The requirements documentation for an information systemapplication would include business areas affected, user scenarios, data forreports, etc. In both cases, this is the information needed to design thesolution.


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 projectproblems. 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 typeat each point in the process.According to Barry Boehm, in "Software Engineering Economics," the relative costto fix an error grows from a value of 1 at Requirements to from 40 - 1000 inOperation. It makes good business sense to do a good job of collecting and verifyingrequirements 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 userdetermines if the requirements correctly reflect the actual needs. Traceability makes thisprocedure 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 alsomust define the responses of the solution to all realizable classes of situations and bothvalid and invalid input values, as well as include definitions of all terms.

Consistent if the documentation is internally consistent -- that is no subset of individualrequirements 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 generalany ambiguous requirement is not verifiable.

Modifiable if its structure and ~tyle are such that any changes to the requirements can bemade easily, completely, and consistently while retaining the structure and style.Modifiability generally requires that the documentation has a coherent and easy-to-useorganization with a table of contents, an index, and explicit cross-referencing. Inaddition, Each requirement should be stated separately and should not appear in morethan one place in the documentation.

Traceable if the origin of each of the stated requirements is clear and if it facilitates thereferencing of each requirement in future development documentation. Backwardtraceability means that each requirement explicitly mentions its source in earlierdocuments. Forward traceability means that each requirement can be located in thedocuments that follow.


Benefits of Good Documentation

• Clear expectations of what the project is toproduce

• 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 gooddocumentation of business objectives and clear requirements. Appropriaterequirements documentation provides several specific benefits:

• Establishes the basis for agreement between the customers and the supplierson what the solution is to do.

• Reduces the development effort. The requirements process ensures that thevarious concerned groups in the customer's organization considerrigorously all of the requirements before design begins, thus reducing laterre-work and re-testing.

• Reveals omissions, misunderstandings, and inconsistencies early in thedevelopment cycle when these problems are easier to correct.

• Provides a basis for estimating costs and schedules. The description of thesolution to be developed is a realistic basis for estimating project costs andschedules.

• Provides a baseline for validation and verification. The requirementsprovide a baseline against which project success can be measured.

• Serves as a basis for enhancement. The requirements documentation servesas a basis for later enhancements to the finished solution.

Software Project Management Session 3: Defining Sr;JftwareRequirements

Requirements and Communication

• The requirements process requires excellentteam and customer communication

• As team understanding and communicationimprove, the teamwork builds

• Corollary: Keep the requirements teaminvolved for the duration of the project

According to Gerald Weinberg in "Exploring Requirements," the "requirementsprocess is the part of development in which people attempt to discover what isdesired."Consequently, the process of developing requirements is actually a process ofdeveloping 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 asthe 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 withconceptual information about the business process and continues to refine thisinformation until a technical solution can be designed to address the originalproblem. Some of this conceptual information is gathered during the initiationand justification for the project.

When the project is approved, "Business Requirements" are collected to furtherdefine the project context in terms of the business and to clarify what thecustomers expect. The next step, "Functional Requirements" identifies whatbusiness processes are supported, and establishes the business features that thesolution should support. The last step, "Technical Requirements" specifies whatthe 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 proposedbusiness process and the overall architecture of the solution. Businessrequirements build on the analysis performed as part of a market analysis orfeasibility study in addition to the Problem/Opportunity analysis performed forthe Project Charter.User interviews at many levels are required to capture and understand the businessrequirements. Executive interviews help to establish the overall interactions.Interviews with middle managers and end users present the detailed view of thebusiness 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 viewof the business interactions. System Context diagrams present a "birds-eye" viewof the system interactions.Business-requirements must be presented in the language of the end user, avoidinguse of technical terms. The purpose of gathering business requirements is to gaina thorough enough understanding of the problem/opportunity and the businessarea to assist the users in specifying the functional and technical requirements forthe most appropriate technology solution.Business requirements describe what the users need to do to perform the taskswhich 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 propertiesof the problem and potential solutions. Many of these questions may have been asked as part ofthe ITB Project Initiation phase. However, they may also be appropriate for interviews at thebeginning of the approach phase. Context -free questions apply no matter what the solution is tobe. In terms of project decisions, these questions help ensure that we are on the right limb insteadof "out on a limb."

Clearly determining the context early in the process helps avoid hearing this:" Oh, we thoughtyou knew that. We always do it that way!"

The answers to the process questions help determine the approach and who is involved in theproject. The answers to the product questions help establish boundary conditions for therequirements. The meta questions help understand the value of the interview and may uncoverhidden 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 questionsAm 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 businessentities 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 userinteractions in the business environment. Use the this tool in the early stages ofgathering business requirements.It is often helpful to diagram each area of the business separately to gain athorough understanding of the transactions in each area. These diagrams can thenbe 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

comPleled~Mana~:ment l"'''TRequest for

Priority

SERVICE REQUEST CURRENT SITUATIONCONTEXT DIAGRAM

09/15199

Business Context diagrams can be used to show the current and proposedinteractions at a conceptual level. The difference between the two diagrams showsthe 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 currentsituation. The Help Desk appears in the proposed solution diagram, showing thatthis new function will need to be added to the organization.


Service Request Proposed SituationService Request

Status

~-"'IMana~menll

" ,/

SERVICE REQUESTI HELP DESKPROPOSED SITUATION

CONTEXT DIAGRAM09115199

The proposed solution also shows a potential Expert System, the result of thesoftware project.


Systems Context Diagram Example

OPERATIONS BRANCHFIS REDESIGN PROJECT

CONTEXT DIAGRAM

BUDGETALLOCATIONS

TIMEREPORTING

INFORMATIONPERSONNEL

INFORMATION

REQUESTEDREPORT

PARAMETERS

REQUESTED~ REPORT

FIELD • ~ PARAMETERS

DIVISIONS REQUESTE~

AND FIELD REPORTOFFICES PARAMETERS

TIME REPORTINGINFORMATION

~UI

WORKLOAD INFORMATION ~

TIME REPORTINGINFORMATION

!PERSONNELl~A"O'

REQUESTEDREPORT

PARAMETERS

TABLEMAINTENANCEINFORMATION

EMPLOYEE TIMEREPORTING

INFORMATIONTIME DISTRIBUTION·

SYSTEM INFORMATION

EMPLOYEE SALARY & ""'-ADDRESS INFORMATION ~

This tool shows the existing system and the user interactions with the system, as opposed to theBusiness Context diagram which presents a bigger picture view of user interactions with eachother. System context diagrams are useful when the project is replacing or interacting with anexisting information system. Business context diagrams are appropriate when the project isautomating 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''!htf:

Functional requirements contain more detail about how the desired businessprocess will operate and specifics about what the solution needs to do in order tosupport these business processes.Functional requirements should maintain independence from the solutionimplementation. For example, if the system requires secure access to data, thenthis 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. Thetechnical requirements and design will define the implementation that meets thesecure 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 CaseScenarios use a standard format to describe the interactions between the users andthe system. The Implementation Checklist ensures that implementation concernsare not overlOOked)The Functional Requirements result in a list that includes specific actions that thesystem must perform as well as attributes that the system implementation mustpossess in order to operate successfully. Examples of such attributes includeresponse time, data volume, data security, and screen resolution ..Functional requirements do not specify the exact solution --- they establishparameters 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 bypicking a starting point and tracing interactions until all the interactions areaccounted for. Use the following guidelines to create Work Flow diagrams:

• Each column on the Work Flow represents an entity or a user classidentified in the Business Context.

• Each block represents a process owned by the entity in which column itappears.

• Each diamond represents a decision point, which is the responsibility of theentity in which column it appears.

• The arrows show flow between the processes. Time progresses from left toright.

• The diagram should show a continuous work flow from the first transactionto one or more possible resolutions for the process selected.

• A given Business Context diagram can generate several Work FlowDiagrams.


Example Work Flow Diagram for the Proposed ServiceRequest Process

SERVICEREQUEST

TEAM LEADER

Note: Customer Contact mayoccur In all shaded processes.In any of these processes, the"S representative and thecustomer may agreG to cancelthe Service Request.

Work Flow Diagram forIT Service Request Process

This Work Flow diagram shows the detailed interactions between the Help Desk Staff and the SecondLevel Support staff who become involved when the Help Desk Staff can't resolve the problemimmediately.


Use Case Scenarios

• Provide a user-centricview of the system

• Are based on thebusiness processesidentified in theworkflow analysis

• Are collected directly from representatives ofthe various user classes in the system

• Serve as a continuing tool for tracking systemrequirements to the business processes

A use case scenario describes a sequence of interactions between the system and anexternal actor, and results in the actor accomplishing some task that is part of thebusi~es~ process workflo~. (!he ~ctor can b~ a person, another softwareapplIcatIOn, or another entIty fhat mteracts WIth the system.

Use cases focus the requirements search on asking the users what they need to dowith the system. According to Karl Weigers in his textbook, "SoftwareRequirements," this is more effective than the traditional approach of asking userswhat they want the system to do for them. It focuses the users' attention on theiractions rather than on the system actions.

Use case modeling is used extensively in object-oriented approaches to softwaredevelopment. However, this technique can be adapted and used with any softwaredevelopment approach.

A typical use case scenario contains the topics identified in the following Use CaseScenario template.


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

This example was downloaded from www.smartdraw.com/resources/examples/software.This websiteis an excellent source for examples of different types of software diagrams.

http://www.smartdraw.com/resources/examples/software.This


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 thesolution resulting from the need to meet specific values of attributes such asresponse time, or volume of data. Examples of implementation constraints thatbecome 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 · Given three days of system training, users must be able to access 90% of the

l 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 businessrelated functional requirements. This means that the project team should focus firston understanding the business results and second on identifying implementationconstraints. Since a team may be more familiar with the technology than with thebusiness area, too often the tendency is to focus on the constraints rather than thebusiness, resulting in a product that is over constrained and underspecified. Bewareof adding constraints that are really design decisions.


1. USAGE ENVIRONMENTUser 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 hardwareExisting hardware for implementationExisting hardware interfacesExisting directives that limit hardware possibilities

Existing databases and software interfacesExisting implementation softwareExisting directives that limit implementation software choicesRequirements for project support softwareDevelopment and testing environment software

Location of users, data, hardware, networksExisting communication protocolsPrinter, terminal, and ports required

System access limitationsData access limitationsSensitivity of dataMulti-level security requirements

6. RELIABILITYUp-time requirementsMaximum recovery time allowedFault tolerance and failure logging requirements

__ Requirement for reconstructing all transactions__ User accountability requirements


Need for frequent enhancementsAnticipated changes in related operationsFuture projects that may affect this project

Constraints imposed by long range business plansImpact on future projects

-Software Project Management Session 3: Defining Software Requirements

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 termsof the features and characteristics that address the functional requirements. Thisinformation rounds out the requirements, providing sufficient detail to begin thedesign 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 andrelationship requirements. Object models, used in Object-oriented approaches,show the relationships between the system components. System interfacediagrams identify physical interface requirements that the solution must meet.

Technical requirements also include models of the system in order to specifycustomer interface needs and gain customer feedback on what the system willlook like. For example system prototypes are especially useful for previewingthe Graphic User Interface (GUI), general screen layouts, reports, or navigationcharts. The Implementation checklist is also used in gathering technicalrequirements in order to identify requirements specific to a particular component,e.g. the user interface or required bandwidth or speed of the specific components.

,,---Software Project Management Session 3: Defining Software Requirements

Example Entity Relationship Diagram (ERD)

Entities

Entities are represented by rectangles. An entity is an object or concept about whichyou want to store information.

AttributesAttributes are represented by ellipses. An Attribute describes properties orcharacteristics of an entity.

RelationshipsRelationships are represented by diamonds. A Relationship illustrates how two entitiesshare information in the database structure.

CardinalityCardinality specifies how many instances of an entity relate to one instance of anotherentity.

This example, along with other ERD and software diagram examples, can be found onwww.smartdraw.com/resources/ examp les/ software.

http://www.smartdraw.com/resources/


Example Object Model: Class DiagramCl.d~'iJ2L~_G~\M : ELECTRO"<tc SIlOP!'):"\, C \R r

s+t:tf~~;l~~~10•• "N"""Expira~te

il~~~',-SlbTotal:MOlleysUsT~ytoto1-_plonOolnO

"""""'"'01

{clIdil1tdbc_ pell

••• s1I)ppq;cu1ob)tCIMfOIlly••• lltcwditcWtcSOCiatedwtthil.

',. credit~D'Upm1'Cbethafpttr~~Omen(C

to let lbtal&bull ,t<mCC'li~eloacW1th·~n1lt'Ul1tClI!lIer~D..

-""""P,rlJtlit:M<mey

tdciltemOJaIOWltmO

The object class diagram is used to describe the static structure of a system in termsof objects and their relationship to each other. Each object is shown with an ObjectName, the data attributes associated with that object, and the procedures that thatobject can perform.


Example Object Architecture Diagram

This example shows the interfaces and inheritances between the major componentsof 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 designthe menus and navigation elements.


Example Web Interface

2. Ql.uestion?

il3. Question?

r Ans"".r(e' Answer

r Answer

r Answer

4. Question?r Answer r Answer

j;7 Ans ••• r r Answe.

5. Question?

S ;;JUR 6. Question?

V (' Answer

r Answer

t' Answer

Customer SurveyQuestions - Part II

8. Question?r Answer

(;7 Answer

10. Question?rAn" .•.", f.' Answer

r Answer r Answer

11. Question?

r Answer

r Ans,,",lIlrIi' Ans ••••er

r Answer

PIQ~5e enter any comment5you may have concemingyour i!ihopping experiencewith us:

"'Special Pl"'Onlotions:

r Promotion 1 • Sign up!

r Promotion 2 - Sign up!

r Promotion 3 • Sign up!

r' Promotion 4 • Sign up!

This web interface mock-up shows users the interface used to collect surveyanswers.


Example Input Screen Prototype

Example input screens, query screens, and reports are essential for presenting thetechnical requirements for end user approval. These screens and reports help toidentify the data which must be kept in the system and clarify how it will bepresented. 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

Clni""Qfj( SSNJeot. Jl_lJt.I-lI~_iJ~ ,_ _ _ . _ ~- . 001l: 'I ~I!YISS2 ,~__3·(;u,i"~~I:;:;.:::::'::.m:.~~=:~~w:::__.::=:~:=:::=::::_~:::··-r·-·::.

~;-SellrdlFind ClaimomFind ChumFuuJ Rln.'JlnllnJf'lmJilnr:uw·~:Verity OQr.:tOf

;.··MyWf1rkJo.ebV6 Cttllifft&;

~pt\. ••Ir.Whd.IJMrtllf.~ceptlol'l'fl~~

~.;.'Uru'&$ig~8d WorkPendinQ C1oimt:AfIJlI!ftb

Y/tllluUtll1ExceptiollSf\eviBWfi

Report$MnQ.1'lIJI~ml~nlHdll

This example query screen shows a data area as well as navigation elementsincluding menus and tabs.


Requirements Traceability Matrix• Prioritized list of all requirements

• Created as requirements are identified

• Shows backward referencing toBusiness Requirements

• Shows dependencies between requirements

• Includes space for forward referencingto module design and test cases

• Will be revised as the project progresses

The Requirements Traceability Matrix is a linked list that tracks all logical andphysical requirements back to the business need and forward to the moduledesign and test cases. It performs several functions as the project proceeds. TheRequirements Traceability Matrix:

• Ensures that when requirements change, their related requirements can beinvestigated to see if they are affected and also need changing;

• Ensures that the solution is based on what was required, and that what isdesigned can be traced back to overall objectives and specificrequirements, and,

• Is used by project management, vendors, designers, developers,acceptance testers and business owners to verify that the requirements aremet.

" Software Project Management Session 3: Defining Software Requirements

Requirements Traceability Matrix Contents

For each requirement:Requirement NumberName/DescriptionSourcePriorityDependenciesSystem Module( s)--TBDTest Case Number(s)--TBD

The Requirements Traceability Matrix tracks key requirements throughout theproject life cycle. Information for each requirement includes the operationalscenario 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 requirementdepends as well as those that are dependent on the given requirement.

The system modules that fulfill the requirement are identified during the Designphase and are completed at that time, as are the specific test cases that validate therequired feature.

The Requirements Traceability Matrix is initialized at the beginning of theRequirements phase and is added to as new requirements are identified.


Requirements Traceability MatrixThe Requirements Traceability Matrix creates a cross referenced list of all logical and physicalrequirements. It identifies dependencies between these requirements, traces each one to an operationalscenario, 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 TestScenario Depends on Essential For Module Cases

[Briefly describe the requirement] [State the Use [Choose [List the [List the TBD TBDCase Scenario one: requirement requirementnumbe that Essential, numbers that numbers thatdrives this Desirable, must be are supportedrequirement] Optional] included to bYth:~

V7Y \. support this require '\t1I, reQuirementl

1., I

\t(9i~\2.

3.

4.

5.

Software Project Management Session 3: Defining Software Requirements,---. ----------------------------------------

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, containsexcellent examples and templates for the following:

• Operations Concept Document - business requirements, operationalconcept, and requirements traceability matrix

• Requirements and Functional Specifications - functional requirements

• Requirements Analysis Report - Summary and technical requirementsincluding data flow or object-oriented diagrams

IEEE standards for requirements documentation include the following:

• IEEE Std 1233 1998 - Guide for Developing System RequirementsSpecifications

• IEEE Std 830 1998 - Recommended Practice for Software RequirementsSpecifications

• IEEE Std 1362 1998 - Guide for Information Technology system Definition- Concept of Operations Document

The IEEE website is http://www.ieee.com.

http://sel.gsfc.nasa.gov,

http://www.ieee.com.


Session Three Review Questions• What makes gathering requirements difficult?

• What are the levels of requirements and howdo they relate to each other?

• What tools would you use to gather anddocument Business Requirements?

• What tools would you use to gather anddocument Functional Requirements?

• What tools would you use to gather anddocument Technical Requirements?

• What is the purpose of a Requirements TraceabilityMatrix?

session 3 - defining software requirements

Documents