DP Software Requirements Analysis V1 2 1

8/16/2019 DP Software Requirements Analysis V1 2 1

1/30

Deployment Package

Software Requirements Analysis

Basic Profile

Notes:This document is the intellectual propriety of its author’s organization. However, informationcontained in this document is free of use. The distribution of all or parts of this document isauthorized for non commercial use as long as the following legal notice is mentioned:

© Centre d’!cellence en Technologies de l’"nformation et de la Communication and #cole deTechnologie $up%rieure

Commercial use of this document is strictly forbidden. This document is distributed in orderto enhance e!change of technical and scientific information.

This material is furnished on an &as'is( basis. The author)s* ma+e)s* no warranties of any

+ind, either e!pressed or implied, as to any matter including, but not limited to, warranty of fitness for purpose or merchantability, e!clusivity, or results obtained from use of thematerial.

The processes described in this eployment -ac+age are not intended to preclude ordiscourage the use of additional processes that ery $mall nterprises may find useful.

Authors

$. /01/23, 4 Centre d’!cellence en Technologies del’"nformation et de la Communication )CT"C*, )5elgium*

C. 6. 0/-73T, #cole de Technologie $up%rieure )T$*, )Canada*

EditorsC. 6. 0/-73T, #cole de Technologie $up%rieure

/2/ /898 4 ;th level, )??=

!ast update >@ ?AB

Status raft

"ersion A.>

© CT"C 4 T$


2/30

Deployment Package # Software Requirements Analysis -age > D?

ersion A.>

"ersions

Date "ersion Auteur $odification?=?E>??= ?.A $. /01/23 ocument creation

>??E>??= ?.> C.6. 0/-73T Comments on document structure

AA?>??= ?.D $. /01/23 "mplementation of comment andfinalization of A.?

AA?>??= ?.@ $. /01/23 Comments after review

EA?>??= ?.; $. /01/23 pdate and completion of section D.A

A@A?>??= ?.B $. /01/234 C.6. 0/-73T

pdate and revision of section D.A

AFA?>??= ?.= $. /01/23 pdate of section D.A and D.>

>FA?>??= ?.E $. /01/23 3eplacement of Gpractice’ by Gactivity’ to comply with 7I $-< terminology.

>AA>??= ?.F $. /01/23 /lignment of the content with"$7A>>?=:>??E.

>=AA>??= ?.A? $. /01/23 pdate of graphical representation of steps.

AA>>??= A.? $. /01/23 Iinal version 4 ready for final review

>A?A>??E A.A $. /01/23 pdate of coverage matri!

=?=>??F A.> C.6. 0/-73T


3/30

Deployment Package # Software Requirements Analysis -age D D?

ersion A.>

)a%le of ontents

1. Technical Description..............................................................................4

Purpose of this document..........................................................................................4Why Requirements Management is Important ?...........................................................4


4/30

Deployment Package # Software Requirements Analysis -age @ D?

ersion A.>

*( )echnical Description

!'rpose of this &oc')ent

This eployment -ac+age )-* supports the 5asic -rofile as defined in "$7"C >FAA? -art;'A:


5/30

Deployment Package # Software Requirements Analysis -age ; D?

ersion A.>

+igure * Pro,ect resolution history

$ain auses of Success

/ccording to the $tandish roup, the main causes of S5CCESS are:

− 2ser In0o"0ement

− !ecutive $upport

− Clear 5usiness 7bJectives

− !perienced -roJect


6/30

Deployment Package # Software Requirements Analysis -age B D?

ersion A.>

+igure - .rigins of software defects

© CT"C 4 T$


7/30

Deployment Package # Software Requirements Analysis -age = D?

ersion A.>

-( Definitions

"n this section, the reader will find two sets of definitions. The first set defines the termsused in all eployment -ac+ages, i.e. generic terms. The second set of terms used in thiseployment pac+age, i.e. specific terms.

6eneric Ter)s

!rocess set of interrelated or interacting activities which transform inputs into outputsP"$7"C A>>?=Q.

#cti$it- a set of cohesive tas+s of a process P"$7"C A>>?=Q.

Tas% reKuired, recommended, or permissible action, intended to contribute to the

achievement of one or more outcomes of a process P"$7"C A>>?=Q.

S'8Tas% Nhen a tas+ is comple!, it is divided into sub'tas+s.

Step "n a deployment pac+age, a tas+ is decomposed in a seKuence of steps.

Role: a defined function to be performed by a proJect team member, such as testing, filing,inspecting, coding. P"$7"C >@=B;Q

!ro&'ct piece of information or deliverable that can be produced )not mandatory* by one

or several tas+s. e. g. design document5 source code6.

#rtefact information, which is not listed in "$7"C >FAA? -art ;, but can help a $during the e!ecution of a proJect.

Specific Ter)s

Re'ire)ent !. a statement that identifies what a product or process must accomplish toproduce reKuired behaviour andor results. I--- !%%*%**' I--- Standard for the $pp"ication and Management of the Systems -ngineering Process. D.A.AB. %. a system orsoftware reKuirement that specifies a function that a systemsoftware system orsystemsoftware component must be capable of performing. IS(,I- %47#'5 Systems and

Soft8are -ngineering 9oca&u"ary. :. a reKuirement that specifies a function that a systemor system component must be able to perform. P"$7"C>@=B;Q

Re'ire)ents anal-sis: The process of studying user needs to arrive at a definition of system, hardware, or software reKuirements. P"$7"C >@=B;Q

Re'ire)ents &oc')ent a document containing any combination of recommendations,reKuirements or regulations to be met by a software pac+age. P"$7"C >@=B;Q

© CT"C 4 T$


8/30

Deployment Package # Software Requirements Analysis -age E D?

ersion A.>

Re'ire)ents phase the period of time in the software life cycle during which thereKuirements for a software product are defined and documented. P"$7"C >@=B;Q

Software Re'ire)ents Specifications: The $3$ is a specification for a particularsoftware product, program, or set of programs that performs certain functions in a specificenvironment. The $3$ may be written by one or more representatives of the supplier, one ormore representatives of the customer, or by both. P"ED?'FEQ

The $3$ document contains both functional and non functional reKuirements.

The $3$ can be materialized in a word document but it can also be managed in a databaseor in an !cel file.

:on 0'nctional Re'ire)ent : a software reKuirement that describes not what thesoftware will do but how the software will do it. "$7"C >@=B;, $ystems and $oftwarengineering ocabulary. $yn. design constraints, non'functional reKuirement. $ee also:functional reKuirement. 27T for e!ample, software performance reKuirements,

software e!ternal interface reKuirements, software design constraints, and software Kualityattributes. 2on functional reKuirements are sometimes difficult to test, so they are usuallyevaluated subJectively. P"$7"C>@=B;Q

Prototype: an e!perimental model, either functional or non functional, of the system or partof the system. I--- !%::5 !))/ -dition R%**%6 I--- Guide for ;e0e"oping SystemRequirements Specifications. D.A>. 2. a preliminary type, form, or instance of a system thatserves as a model for later stages or for the final, complete version of the system. IS(,I- %47#'5 Systems and Soft8are -ngineering 9oca&u"ary. 3. model or preliminaryimplementation of a piece of software suitable for the evaluation of system design,performance or production potential, or for the better understanding of the softwarereKuirements. IS(,I- !')!*


9/30

Deployment Package # Software Requirements Analysis -age F D?

ersion A.>

0( Relationships with 1S.'1E -2**3This deployment pac+age covers the activities related to reKuirements analysis of the "$7Technical 3eport "$7"C >FAA? -art ;'A for ery $mall ntities )$s* 4 5asic -rofileP"$7"C>FAA?Q.

"n this section, the reader will find a list of applicable -roJect .@ alidation of the Requirements Specification

alidate that Requirements Specification satisfies needs andagreed upon e!pectations, including the user interfaceusability. The results found are documented in a 9a"idationResu"ts and corrections are made until the document isapproved by C$.

C$, /2

$".>.; ocument the preliminary version of the Soft8are 2ser ;ocumentation or update the present manual.

)optional*

/2

$".>.B erification of the Soft8are 2ser ;ocumentation

erify consistency of the Soft8are 2ser ;ocumentation withthe Requirement Specification. .The results found aredocumented in a 9erification Resu"ts and corrections are madeuntil the document is approved by /2. "f significant changes

/2

© CT"C 4 T$


10/30

Deployment Package # Software Requirements Analysis -age A? D?

ersion A.>

)ask !ist Role

were needed, initiate a hange Request. )optional*

$".>.= "ncorporate the Requirements Specification5 andRSoft8are 2ser ;ocumentation to the Soft8are onfigurationin the baseline. R)optional*

T0

© CT"C 4 T$


11/30

Deployment Package # Software Requirements Analysis -age AA D?

ersion A.>

4( Description of Processes5 Acti&ities5 )asks5 Steps5

Roles and Products

Process: Software 1mplementation

Acti&ity: $".> $oftware reKuirements analysis

)ask !ist Role

$".>.A /ssign tas+s to the Nor+ Team members in accordancewith their role, based on the current Pro=ect P"an.

T0, NT

$".>.> ocument or update the Requirements Specification. /2, C$

$".>.D erification of the Requirements Specification. /2

$".>.@ alidation of the Requirements Specification C$, /2

$".>.; ocument the preliminary version of the Soft8are 2ser ;ocumentation or update the present manual. )optional*

/2

$".>.B erification of the Soft8are 2ser ;ocumentation /2

$".>.= "ncorporate the Requirements Specification5 andRSoft8are 2ser ;ocumentation to the Soft8are onfiguration inthe baseline. R)optional*

T0

Tas%s

Requirements identification

O8;ecti$es The obJective of this activity is to clearly define the scope of the proJectand identify the +ey reKuirements of the system.

Rationale "t is important to clearly define the proJect scope )boundaries* and toidentify +ey functionalities of the future system with the customer toavoid problems li+e forgotten +ey functionalities or reKuirements creep.

Roles -roJect . "dentify proJect’s scope

D. "dentify and capture reKuirements

@. $tructure and prioritize reKuirements

© CT"C 4 T$


12/30

Deployment Package # Software Requirements Analysis -age A> D?

ersion A.>

StepDescription

Step 1. Collect infor)ation a8o't the &o)ain:

uring this $tep, analyst captures the +ey concepts of the businessdomain of the customer. The customer assists the analyst by givinghim all the information )e!isting documentation or e!planation* that

will facilitate this understanding.Sey concepts are listed in a glossary section in the Soft8areRequirements Specification ;ocument out"ine document.

Step 2. I&entif- pro;ect


13/30

Deployment Package # Software Requirements Analysis -age AD D?

ersion A.>

Rationale "t is important to go through identified reKuirements in order to detectreKuirements that seem easy to implement but hiding a businesscomple!ity that will cause problems in the proJect.

Roles /nalyst

Customer

eveloper

#rtefacts se Cases 4 scenarios

3eKuirements ocument

$oftware prototype

Steps A. etail reKuirements

>. -roduce a prototype

Step

Description

Step 1. Detail re'ire)ents

The analyst goes through a set of identified reKuirements and performs

a more detailed analysis.5usiness comple!ity can be implicit for some reKuirements. This mustbe clarified at this point before any implementation.

The analyst will interact with customer representatives in order toclarify ergonomic Kuestion, if relevant )e.g. if a raphical ser"nterface must be developed*.

This $teps results in a new version of the Soft8are RequirementsSpecification ;ocument.

Step 2. !ro&'ce a protot-pe

-roducing a prototype can facilitate reKuirement understanding from allproJect participants )i.e. customer side and development team side*. /prototype may only implement some of the functionalities.

Requirements &erification 6 &alidation

O8;ecti$es erify reKuirements and obtain validation from the customer or hisrepresentative.

Rationale "n order to avoid constant fundamental changes in the reKuirements, itis important to as+ for the reKuirement validation from the customer.

Roles /nalystCustomer

-roJect


14/30

Deployment Package # Software Requirements Analysis -age A@ D?

ersion A.>

Steps A. Clarify fuzzy reKuirements )verification*

>. 3eview software reKuirements specification

D. alidate reKuirements

Description Step 1. Clarif- f'==- re'ire)ents

3eview reKuirements in order to detect reKuirements that are not clearenough )customer or software developer could understand itdifferently*.

Theses criteria can be used to perform this review:

• Clear )avoid ambiguous reKuirements*

• niKue )i.e. avoid two reKuirements stating the same thing*

• Ieasible )according proJect allocated resources*

• Testable

Step 2. Re$iew software re'ire)ents specification

uring this $tep reKuirements are roughly reviewed with the customerin order to be sure that reKuirements are:

• Complete

• Correct

Tips: This $tep can be iteratively done by reviewing a given subset of reKuirements. $oftware engineers must be involved in order to identifytechnical dependencies between reKuirements )i.e. 3eKuirement /must be implemented before reKuirement 5 due to implementation

reason.*

Step 3. >ali&ate re'ire)ents

7btain from your customer an approval of the reKuirements )or of agiven subset if you are using an iterative lifecycle*.

Requirements change management

O8;ecti$es To manage reKuirements change according with a process agreed uponwith the customer.

Rationale 3eKuirements change is a permanent feature of most of the "TproJects. Change management must be planned and agreed upon withthe customer on the proJect.

Roles /nalyst

-roJect


15/30

Deployment Package # Software Requirements Analysis -age A; D?

ersion A.>

>. /nalyze impact of changes

D. "dentify changes that are out of the proJect scope

@. -rioritize changes

Description Step 1. Trac% chanes to re'ire)ents

This $tep aims to collect and manage in a central repository )can be ane!cel sheet or any other database* any changes that are formulatedagainst reKuirements.

This encompasses changes to e!isting reKuirements but also new ordeleted reKuirements.

Step 2. #nal-=e i)pact of chanes

"dentify the impact on the proJect schedule and cost of each of thereKuested changes.

Step 3. I&entif- chanes that are o't of the pro;ect scope

/nalyst helped by the person in charge of the contractual aspects of the proJect )sales manager* identifies changes that are out of theproJect scope. Changes that could impact the proJect budget should bediscussed with the customer.

Step 4. !rioriti=e chanes

uring this $tep, the proJect manager must obtain from the customer aprioritization of the identified changes in order to adapt the proJectplanning.

© CT"C 4 T$


16/30

Deployment Package # Software Requirements Analysis -age AB D?

ersion A.>

Roles

Role Definition

Analyst

-erson in charge within the development team to gather,analyze and manage the reKuirements related to the softwareto be developed.

ustomer

-erson in charge within the customer side to transfer andvalidate reKuirements to the development team. "t can be thecustomer or any representative.

De&eloper -erson in charge of the development of the software.

Pro,ect $anager-erson in charge of managing the proJect )cost, schedule,tas+s, contract,*

)a%le * Definitions of Roles

#rtefacts

Artefacts Definition

se Cases 4 scenariosescription of a seKuence of interactions between the userand the future systems. ses cases can be written asprescribed by


17/30

Deployment Package # Software Requirements Analysis -age A= D?

ersion A.>

7( )emplateThe templates provided with this deployment pac+age should be customized for yourproJect.

SRS )emplate )a%le of ontent #Basic !ist of Requirements

To be used in an !cel sheet structured, for e!ample, as:

I

;

Requirement ;escription Priority

SRS )emplate )a%le of ontent #Adapted from 1EEE 803

*( 1ntroduction

A.A -urpose

A.> ocument conventions

A.D "ntended audience

A.@ /dditional information

A.; Contact information$3$ team members

A.B 3eferences

-( .&erall Description

>.A -roduct perspective>.> -roduct functions

>.D ser classes and characteristics

>.@ 7perating environment

>.; ser environment

>.B esignimplementation constraints

>.= /ssumptions and dependencies

0( E/ternal 1nterface Requirements

D.A ser interfaces

D.> Hardware interfacesD.D $oftware interfaces

D.@ Communication protocols and interfaces

4( System +eatures

@.A $ystem feature /

@.A.A escription and priority

@.A.> /ctionresult

© CT"C 4 T$


18/30

Deployment Package # Software Requirements Analysis -age AE D?

ersion A.>

@.A.D Iunctional reKuirements

@.> $ystem feature 5

7( .ther Non functional Requirements;.A -erformance reKuirements

;.> $afety reKuirements

;.D $ecurity reKuirements

7(4 Software quality attri%utes

;.; -roJect documentation

;.B ser documentation

9( .ther Requirements

/ppendi! /: Terminologylossaryefinitions list

/ppendi! 5: To be determined

© CT"C 4 T$


19/30

Deployment Package # Software Requirements Analysis -age AF D?

ersion A.>

SRS )emplate )a%le of ontent onstru/-

> www.constru!.com© CT"C 4 T$


20/30

Deployment Package # Software Requirements Analysis -age >? D?

ersion A.>

SRS )emplate )a%le of ontent # "olere0

D http:atlsysguild.comuild$ite3obsTemplate.html© CT"C 4 T$


21/30

Deployment Package # Software Requirements Analysis -age >A D?

ersion A.>

SRS)emplate )a%le of ontent # "olere Requirement Shell

© CT"C 4 T$


22/30

Deployment Package # Software Requirements Analysis -age >> D?

ersion A.>

9( E/ample of !ifecycleDisclai)er : This section pro0ides some graphica" representation of e+amp"e of requirement practices "ifecyc"e. These e+amp"es are pro0ided to he"p the reader to imp"ement his o8n requirement "ifecyc"e fitting his IT pro=ects conte+t and constraints.

E/ample * of Requirement Practices !ifecycle

+igure 0 E/ample * of Requirement Practices !ifecycle

© CT"C 4 T$


23/30

Deployment Package # Software Requirements Analysis -age >D D?

ersion A.>

E/ample - of Requirement Practices !ifecycle

+igure 4 E/ample - of Requirement Practices !ifecycle

© CT"C 4 T$


24/30

Deployment Package # Software Requirements Analysis -age >@ D?

ersion A.>

;( hecklist

Re'ire)ent chec%list

This 3eKuirement chec+list is based on PConstr?=Q

RS * )esta%le /ll reKuirements are verifiable )obJectively*

RS - omplete /re the reKuirements completeU

RS 0 )racea%le /ll reKuirements must be traceable to a systems specification,contractualproposal clause.

RS 4 orrect 3eKuirements must be correct )i.e. reflect e!actly customer’sreKuirements*

RS 7 uality 9uality attributes have been defined.

RS *3


25/30

Deployment Package # Software Requirements Analysis -age >; D?

ersion A.>

8( )ool

Tracea8ilit- Tool

• 7bJectives:

– To maintain the lin+age from the source of each reKuirement through itsdecomposition to implementation and test )verification*.

– To ensure that all reKuirements are addressed and that only what is reKuired isdeveloped.

– seful when conducting impact assessments of reKuirements, design or otherconfigured item changes.

1nstructions

The above table should be created in a spreadsheet or database such that it may be easilysorted by each column to achieve bi'directional traceability between columns. The uniKueidentifiers for items should be assigned in a hierarchical outline form such that the lowerlevel )i.e. more detailed* items can be traced to higher items.niKue 3eKuirement "dentification )"* The niKue 3eKuirement " $ystem 3eKuirement $tatement where the

reKuirement is referenced, andor the uniKue identification )"* fordecomposed reKuirements

3eKuirement escription nter the description of the reKuirement )e.g., Change 3eKuestdescription*.

esign 3eference nter the paragraph number where the C3 is referenced in the designdocumentation


26/30

Deployment Package # Software Requirements Analysis -age >B D?

ersion A.>

?uideline 3eKuirements traceability should:• nsure traceability for each level of decomposition performed on

the proJect. "n particular:o nsure that every lower level reKuirement can be traced

to a higher level reKuirement or original sourceo nsure that every design, implementation, and test

element can be traced to a reKuiremento nsure that every reKuirement is represented in design

and implementationo nsure that every reKuirement is represented in

testingverification• nsure that traceability is used in conducting impact

assessments of reKuirements changes on proJect plans, activitiesand wor+ products

• 5e maintained and updated as changes occur.

• 5e consulted during the preparation of "mpact /ssessments forevery proposed change to the proJect

• 5e planned for, since maintaining the lin+sreferences is a laborintensive process that should be trac+edmonitored and shouldbe assigned to a proJect team member

• 5e maintained as an electronic document

© CT"C 4 T$


27/30

Deployment Package # Software Requirements Analysis -age >= D?

ersion A.>

2( References to .ther Standards and $odelsThis section provides references of this deployment pac+age to "$7"C $tandards and tothe Capability .A etermination of reKuirementsrelated to the product

The organization shall determine

a* reKuirements specified by thecustomer, including the reKuirementsfor delivery and post'deliveryactivities,

@$< C


28/30

Deployment Package # Software Requirements Analysis -age >E D?

ersion A.>

ISO/IEC 1227 Reference atri+

)itle of the )ask and Step o&erage

+'P

lause of 1S.'1E *--3; omments

3eKuirements identification

$tep A ' Collect informationabout the applicationdomain


$tep > ' "dentify proJect’sscope

-

=.A.> $oftware 3eKuirements/nalysis -rocess=.A.>.> 7utcomes

CI Reference atri+

)itle of the )ask and Step o&erage

+'P

.%,ecti&e' Practice of $$1 "*(- omments


$tep A ' Collect informationabout the application

domain

-


$tep > ' "dentify proJect’sscope

-$ A evelop Customer3eKuirements

© CT"C 4 T$


29/30

Deployment Package # Software Requirements Analysis -age >F D?

ersion A.>

*3( References

@ey ReferenceP"$7"C >FAA?Q $oftware ngineering X 0ifecycle -rofiles for ery $mall ntities )$s*

X -art ;'A: AAFQ "$7"C A>AAF:AFF@ "nformation technology 4 $oftware pac+ages ''9uality reKuirements and testing.

P"$7"CA>>?=Q "$7"C A>>?=:>??E $ystems and software engineering ' $oftware lifecycle processes.

P"$7"C>@=B;Q "$7"C >@=B;, $ystems and $oftware ngineering ocabulary

PConst$oft?>Q Constru! $oftware 4 Chec+list for $oftware 3eKuirements$pecifications, >??>.

P$05?=Q $elby, -., $elby, 3.N.,


30/30

Deployment Package # Software Requirements Analysis -age D? D?

ersion A.>

**( E&aluation +orm

Deployment Package # Software Requirements Analysis # "ersion *(-6our feedbac+ will allow us to improve this pac+age, your comments and suggestions arewelcomed

*( =ow satisfied are you with the .N)EN) of this deployment package

9ery Satisfied Satisfied @either Satisfied nor ;issatisfied ;issatisfied 9ery ;issatisfied

-( )he sequence in which the topics are discussed5 are logical and easy to follow

9ery Satisfied Satisfied @either Satisfied nor ;issatisfied ;issatisfied 9ery ;issatisfied

0( =ow satisfied were you with the APPEARANE'+.R$A) of this deployment

package 9ery Satisfied Satisfied @either Satisfied nor ;issatisfied ;issatisfied 9ery ;issatisfied

4( =a&e any unnecessary topics %een included please descri%eC

7( hat missing topic would you like to see in this package please descri%eC

• -roposed topic:

• 3ationale for new topic

9( Any error in this deployment package

• -lease indicate:

• escription of error :

• 0ocation of error )section Y, figure Y, table Y* :

;( .ther feed%ack or comments:

8( ould you recommend this Deployment package to a colleague from another"SE

;efinite"y Pro&a&"y @ot Sure Pro&a&"y @ot ;efinite"y @ot .ptional

• 2ame:• e'mail address : ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Email this form to : simon.ale!andre[cetic.be or: claude.y.laporte[etsmtl.ca or/vume!>??D[yahoo.com.m!
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]

Documents

DP Software Requirements Analysis V1 2 1