Download to read offline
LECT3.ppt on software development life cycle
- 1. 1 Requirements Analysis and Specification(Lecture 3)
- 2. 2 Requirements Analysis and Specification Manyprojects fail: because they start implementing the system: without determining whether they are building what the customer really wants.
- 3. 3 Requirements Analysis and Specification Itis important to learn: requirements analysis and specification techniques thoroughly.
- 4. 4 Requirements Analysis and Specification Goalsof requirements analysis and specification phase: fully understand the user requirements remove inconsistencies, anomalies, etc. from requirements document requirements properly in an SRS document
- 5. 5 Requirements Analysis and Specification Theperson who undertakes requirements analysis and specification: known as systems analyst: collects data pertaining to the product analyzes collected data: to understand what exactly needs to be done. writes the Software Requirements Specification (SRS) document.
- 6. 6 Requirements Analysis and Specification Finaloutput of this phase: Software Requirements Specification (SRS) Document. The SRS document is reviewed by the customer. reviewed SRS document forms the basis of all future development activities.
- 7. 7 Requirements Analysis Requirements analysis consistsof two main activities: Requirements gathering Analysis of the gathered requirements
- 8. 8 Requirements Analysis Analyst gathersrequirements through: observation of existing systems, studying existing procedures, discussion with the customer and end-users, analysis of what needs to be done, etc.
- 9. 9 Requirements Gathering If theproject is to automate some existing procedures e.g., automating existing manual accounting activities, the task of the system analyst is a little easier analyst can immediately obtain: input and output formats accurate details of the operational procedures
- 10. 10 Requirements Gathering (CONT.) In theabsence of a working system, lot of imagination and creativity are required. Interacting with the customer to gather relevant data: requires a lot of experience.
- 11. 11 Requirements Gathering (CONT.) Some desirableattributes of a good system analyst: Good interaction skills, imagination and creativity, experience.
- 12. 12 Analysis of theGathered Requirements After gathering all the requirements: analyze it: Clearly understand the user requirements, Detect inconsistencies, ambiguities, and incompleteness. Incompleteness and inconsistencies: resolved through further discussions with the end-users and the customers.
- 13. 13 Analysis of theGathered Requirements (CONT.) Requirements analysis involves: obtaining a clear, in-depth understanding of the product to be developed, remove all ambiguities and inconsistencies from the initial customer perception of the problem.
- 14. 14 Analysis of theGathered Requirements (CONT.) It is quite difficult to obtain: a clear, in-depth understanding of the problem: especially if there is no working model of the problem.
- 15. 15 Analysis of theGathered Requirements (CONT.) Experienced analysts take considerable time: to understand the exact requirements the customer has in his mind.
- 16. 16 Analysis of theGathered Requirements (CONT.) Experienced systems analysts know - often as a result of painful experiences --- without a clear understanding of the problem, it is impossible to develop a satisfactory system.
- 17. 17 Analysis of theGathered Requirements(CONT.) Several things about the project should be clearly understood by the analyst: What is the problem? Why is it important to solve the problem? What are the possible solutions to the problem? What complexities might arise while solving the problem?
- 18. 18 Analysis of theGathered Requirements(CONT.) After collecting all data regarding the system to be developed, remove all inconsistencies and anomalies from the requirements, systematically organize requirements into a Software Requirements Specification (SRS) document.
- 19. 19 Software Requirements Specification Main aimof requirements specification: systematically organize the requirements arrived during requirements analysis document requirements properly.
- 20. 20 Software Requirements Specification The SRSdocument is useful in various contexts: statement of user needs contract document reference document definition for implementation
- 21. 21 Software Requirements Specification:A Contract Document Requirements document is a reference document. SRS document is a contract between the development team and the customer. Once the SRS document is approved by the customer, any subsequent controversies are settled by referring the SRS document.
- 22. 22 Software Requirements Specification: AContract Document Once customer agrees to the SRS document: development team starts to develop the product according to the requirements recorded in the SRS document. The final product will be acceptable to the customer: as long as it satisfies all the requirements recorded in the SRS document.
- 23. 23 SRS Document (CONT.) TheSRS document is known as black-box specification: the system is considered as a black box whose internal details are not known. only its visible external (i.e. input/output) behavior is documented. S Input Data Output Data
- 24. 24 SRS Document (CONT.) SRSdocument concentrates on: what needs to be done carefully avoids the solution (“how to do”) aspects. The SRS document serves as a contract between development team and the customer. Should be carefully written
- 25. 25 Properties of agood SRS document It should be concise and at the same time should not be ambiguous. It should specify what the system must do and not say how to do it. Easy to change., i.e. it should be well-structured. It should be consistent. It should be complete.
- 26. 26 Properties of agood SRS document (cont...) It should be traceable you should be able to trace which part of the specification corresponds to which part of the design and code, etc and vice versa.
- 27. 27 SRS Document (CONT.) SRSdocument, normally contains three important parts: functional requirements, nonfunctional requirements, constraints on the system.
- 28. 28 SRS Document (CONT.) Itis desirable to consider every system: performing a set of functions {fi}. Each function fi considered as: transforming a set of input data to corresponding output data. Input Data Output Data fi
- 29. 29 Example: Functional Requirement F1: SearchBook Input: an author’s name: Output: details of the author’s books and the locations of these books in the library. Author Name Book Details f1
- 30. 30 Functional Requirements Functional requirements describe: Aset of high-level requirements Each high-level requirement: takes in some data from the user outputs some data to the user Each high-level requirement: might consist of a set of identifiable functions
- 31. 31 Functional Requirements For eachhigh-level requirement: every function is described in terms of input data set output data set processing required to obtain the output data set from the input data set
- 32. 32 Nonfunctional Requirements Characteristics of thesystem which can not be expressed as functions: maintainability, portability, usability, etc.
- 33. 33 Nonfunctional Requirements Nonfunctional requirements include: reliabilityissues, performance issues, human-computer interface issues, Interface with other external systems, security, maintainability, etc.
- 34. 34 Constraints Constraints describe thingsthat the system should or should not do. For example, standards compliance how fast the system can produce results • so that it does not overload another system to which it supplies data, etc.
- 35. 35 Examples of constraints Hardwareto be used, Operating system or DBMS to be used Capabilities of I/O devices Standards compliance Data representations by the interfaced system
- 36. 36 Organization of theSRS Document Introduction. Functional Requirements Nonfunctional Requirements External interface requirements Performance requirements Constraints
- 37. 37 Representation of complex processinglogic: Decision trees Decision tables
- 38. 38 Decision Trees Decision trees: edgesof a decision tree represent conditions leaf nodes represent actions to be performed. A decision tree gives a graphic view of: logic involved in decision making corresponding actions taken.
- 39. 39 Example: LMS A LibraryMembership automation Software (LMS) should support the following three options: new member, renewal, cancel membership.
- 40. 40 Example: LMS When thenew member option is selected, the software asks details about the member: name, address, phone number, etc.
- 41. 41 Example(cont.) If proper informationis entered, a membership record for the member is created a bill is printed for the annual membership charge plus the security deposit payable.
- 42. 42 Example(cont.) If the renewaloption is chosen, LMS asks the member's name and his membership number checks whether he is a valid member. If the name represents a valid member, the membership expiry date is updated and the annual membership bill is printed, otherwise an error message is displayed.
- 43. 43 Example(cont.) If the cancelmembership option is selected and the name of a valid member is entered, the membership is cancelled, a cheque for the balance amount due to the member is printed the membership record is deleted.
- 44. 44 Decision Tree New member Renewal Cancel Invalid option -Create record - Get details - Print bills - Get Details - Update record - Print bills - Get Details - Print Cheque - Delete record - Print error message User input
- 45. 45 Decision Table Decision tablesspecify: which variables are to be tested what actions are to be taken if the conditions are true, the order in which decision making is performed.
- 46. 46 Decision Table A decisiontable shows in a tabular form: processing logic and corresponding actions Upper rows of the table specify: the variables or conditions to be evaluated Lower rows specify: the actions to be taken when the corresponding conditions are satisfied.
- 47. 47 Decision Table In technicalterminology, a column of the table is called a rule: A rule implies: if a condition is true, then execute the corresponding action.
- 48. 48 Example: Conditions Valid selectionNO YES YES YES New member -- YES NO NO Renewal -- NO YES NO Cancellation -- NO NO YES Actions Display error message -- -- -- Ask member's name etc. Build customer record -- -- -- Generate bill -- -- Ask membership details -- Update expiry date -- -- -- Print cheque -- -- -- Delete record -- -- --
- 49. 49 Comparison Both decision tablesand decision trees can represent complex program logic. Decision trees are easier to read and understand when the number of conditions are small. Decision tables help to look at every possible combination of conditions.
- 50. 50 Formal Specification A formalspecification technique is a mathematical method to: accurately specify a system verify that implementation satisfies specification prove properties of the specification
- 51. 51 Formal Specification Advantages: Well-defined semantics,no scope for ambiguity Automated tools can check properties of specifications Executable specification
- 52. 52 Formal Specification Disadvantages offormal specification techniques: Difficult to learn and use Not able to handle complex systems
- 53. 53 Formal Specification Mathematical techniquesused include: Logic-based set theoretic algebraic specification finite state machines, etc.
- 54. 54 Semiformal Specification Structured specificationlanguages SADT (Structured Analysis and Design Technique) PSL/PSA (Problem Statement Language/Problem Statement Analyzer) PSL is a semi-formal specification language PSA can analyze the specifications expressed in PSL
- 55. 55 Executable Specification Language If specificationis expressed in formal language: it becomes possible to execute the specification to provide a system prototype. However, executable specifications are usually slow and inefficient.
- 56. 56 Executable Specification Language Executable specificationsonly test functional requirements: If non-functional requirements are important for some product, the utility of an executable specification prototype is limited.
- 57. 57 4GLs 4GLs (Fourth Generation Languages)are examples of executable specification languages. 4GLs are successful because there is a lot of commonality across data processing applications.
- 58. 58 4GLs 4GLs rely onsoftware reuse where common abstractions have been identified and parameterized. Rewriting 4GL programs in higher level languages: result in upto 50% lower memory requirements also the programs run upto 10 times faster.