Lezione 2 Lezione 2 Software requirements requirements Software - PDF document

Corso di Laurea Magistrale Corso di Laurea Magistrale in in Ingegneria Informatica Ingegneria Informatica per la Gestione d’ ’azienda azienda per la Gestione d Gestione della Qualità-II parte Il progetto software: metodologie e standards a.a. 2010 a.a. 2010- -2011 2011 Docente: Gigliola Vaglini Docente: Gigliola Vaglini 1 1 Lezione 2 Lezione 2 Software requirements requirements Software 2 2 1

Requirements analysis Requirements analysis  This This phase phase includes includes   the the definition definition of of functionalities functionalities, , constraints constraints, ,  interfaces interfaces, performance and , performance and any any characteristic characteristic the the software software must must have have to to be be able able to to satisfy satisfy the client the client’ ’s s needs needs  Software Software customers customers have have to to accurately accurately describe describe  what what they they wish wish to to obtain obtain, , while while software software suppliers suppliers have to to understand understand exactly exactly what what the the customers customers want want. . have  This This phase phase does does not not include include   the the definition definition of of the way in the way in which which the software the software will will  be be built built 3 3 The next next phase phase must must The  Establish Establish the the basis basis for for the agreement the agreement between between the the  customers and the and the suppliers suppliers on on what what the software the software customers product is is to to do. do. product – The complete The complete description description of of the the functions functions to to be be performed performed – by by the software the software will will assist the assist the users users to to determine determine if if the the software software meets meets their their needs needs or or how how the software the software must must be be modified modified to to meet meet their their needs needs. .  Reduce the Reduce the development development effort effort. .  – – The The preparation preparation of of a a document document forces forces the the customers customers to to consider rigorously rigorously all all of of the the requirements requirements before before design design consider begins and and reduces reduces later later redesign redesign, , recoding recoding, and , and retesting retesting. . begins Careful Careful review review of of the the specified specified requirements requirements can can reveal reveal omissions omissions, , misunderstandings misunderstandings, and , and inconsistencies inconsistencies early early in the in the development development cycle cycle when when these these problems problems are are easier easier to to correct. . correct 4 4 2

Cont. Cont .  Provide Provide a a basis basis for for estimating estimating costs costs and and schedules schedules. .  – The The description description of of the the product product is is a a realistic realistic basis basis for for – estimating estimating project project costs costs. .  Provide Provide a a baseline baseline for for validation validation and and verification verification. .  – Organizations Organizations can can develop develop their their validation validation plans plans much much more more – productively productively , , as as a part a part of of the the development development contract contract, the , the specification specification document document provides provides a a baseline baseline against against which which compliance can can be be measured measured. . compliance  Facilitate transfer. Facilitate transfer.  – A – A good good specification specification document document makes makes it it easier easier to to transfer the transfer the software product product to to new new users users or or new new machines machines. . software  Serve Serve as as a a basis basis for for enhancement enhancement. .  – The – The document document may may need need to to be be altered altered, , but but it it does does provide provide a a foundation for for continued continued production production evaluation evaluation. . foundation 5 5 IEEE Std Std 830 830- -1998 1998 IEEE  IEEE IEEE Std Std 830 830- -1998 1998 is is the IEEE the IEEE  Recommended Practice Practice for for Software Software Recommended Requirements Specifications Requirements Specifications and and describes the describes the recommended recommended approaches approaches for this this purpose purpose. . for  It It is is based based on a on a model model in in which which the the result result  of the software the software requirements requirements of specification process process is is a a specification specification specification document. . document 6 6 3

Software oftware R Requirements equirements S Specification pecification (SRS) (SRS) S  The The specification specification document document is is called called  Software Requirements Software Requirements Specification Specification (SRS SRS), ), which which must must be be complete, complete, ( correct, , consistent consistent, , unambiguous unambiguous and and correct understandable both both by by customers customers and and understandable suppliers. . suppliers 7 7 IEEE STD 830-1998 Software Requirement Specification (I st versione 1993) 8 8 4

Considerations for for producing producing a a Considerations good SRS SRS good Some information should Some information should be be considered considered when when   writing an writing an SRS. SRS. 1. 1. Nature of Nature of the SRS; the SRS; 2. Environment 2. Environment of of the SRS; the SRS; 3. Characteristics Characteristics of of a a good good SRS; SRS; 3. 4. Joint Joint preparation preparation of of the SRS; the SRS; 4. 5. SRS 5. SRS evolution evolution; ; 6. Prototyping 6. Prototyping; ; 7. Embedding Embedding design in the SRS; design in the SRS; 7. 8. Embedding Embedding project project requirements requirements in the SRS. in the SRS. 8. 9 9 1. Nature of of the SRS the SRS 1. Nature The basic basic issues issues that that the SRS the SRS writer writer(s) (s) shall shall address address are the are the The following following: : Functionality Functionality. .   – – What What is is the software the software supposed supposed to to do? do? External interfaces External interfaces. .   – – How How does does the software the software interact interact with with people, the system people, the system’ ’s hardware, s hardware, other hardware and hardware and other other software? software? other Performance. Performance.   – What is is the the speed speed, , availability availability, , response response time time, , recovery recovery time time of of various various – What software functions software functions, etc.? , etc.? Attributes. . Attributes   – – What are the What are the portability portability, , correctness correctness, , maintainability maintainability, security, etc. , security, etc. considerations? ? considerations Design Design constraints constraints imposed imposed on on an an implementation implementation. .   – – Are there Are there any any required required standards standards in in effect effect, , implementation implementation language language, , policies policies for for database database integrity integrity, , resource resource limits limits, , operating operating environment(s) etc.? (s) etc.? environment 10 10 5

2. Environment 2. Environment of of the SRS the SRS  SRS SRS should should correctly correctly define define all all of of the the  software requirements software requirements. A software . A software requirement may may exist exist because because of of the the requirement nature of of the task the task to to be be solved solved or or nature because of of a a special special characteristic characteristic of of the the because project. project.  A A properly properly written written SRS SRS limits limits the the range range  of valid of valid designs designs, , but but does does not not specify specify any any particular design and particular design and not not impose impose additional constraints constraints on the software. on the software. additional 11 11 3. SRS quality quality attributes attributes 3. SRS  A A good good SRS SRS must must be be  1) UNAMBIGOUS 1) UNAMBIGOUS 2) CORRECT 2) CORRECT 3) COMPLETE 3) COMPLETE 4) VERIFIABLE 4) VERIFIABLE 5) CONSISTENT 5) CONSISTENT 6) MODIFIABLE 6) MODIFIABLE 7) TRACEABLE 7) TRACEABLE 8) RANKED (for for importance importance and/or and/or stability stability) ) 8) RANKED ( 12 12 6

3.1 Unambigous 3.1 Unambigous 13 13 3.2 Correct Correct 3.2  An SRS An SRS is is correct correct if if, and , and only only if if, ,  every requirement requirement stated stated therein therein is is every one that that the software the software shall shall meet meet. . one 14 14 7