1. Chapter 14 Requirements and Specifications

2. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-2 Software Engineering The implementation of a transaction processing application is a significant engineering endeavor –The project must complete On time On budget –The completed system must Satisfy the customer’s needs Meet every one of its requirements Operate efficiently and reliably

3. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-3 Software Engineering Those goals are surprisingly difficult to achieve According to a published study of 16,000 IT projects –Only 16% completed successfully – on time and on budget –Of those that did not complete successfully Average completion time was 222% over schedule Average cost was 189% over budget 31% were cancelled before they were completed

4. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-4 Good Software Engineering Practice Bases on many years of experience, the recommended steps in carrying out a Software Engineering project are: Statement of Objectives –Brief statement made by the customer of what the objectives of the system are

5. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-5 Steps in a Software Engineering Project (cont’d) Requirements Document –Expansion of Statement of Objectives –Describes what the system is supposed to do Not how it does it (that is in the Design Document) –Prepared by customer –In some contexts, the Requirements Document is a request for proposal from the customer to various implementation groups that might want to build the system

6. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-6 Steps in a Software Engineering Project (cont’d) Specification Document –An expanded version of the Requirements Document –Describes in great detail exactly what the system is supposed to do In particular the entire user interface must be specified, including all screens, all controls, etc –Prepared by implementation group in collaboration with customer –In some contexts, the Specification Document is a contract between the implementation group and the customer as to what will be delivered

7. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-7 Steps in a Software Engineering Project (cont’d) The remaining steps are described in Chapter 15 –Design Document –Test Plan –Code –Testing –Delivery

8. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-8 Requirements Document for the Student Registration System A complete Requirements Document for the Student Registration System is given in the text –Requirements are numbered so they can be referred to in other documents, such as the Test Plan, which must ensure that a test exists for each requirement –Requirements are stated with words such as “must” and “shall” Words such as “should” and “can” do not connote a mandatory requirement and should be avoided

9. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-9 Use Cases A common way to describe requirements is with Use Cases A use case is a set of actions that produce benefits to one or more users called actors –Students register for a course Analysts develop the requirements as a set of use cases –Analysts work with the users to develop the use cases by asking them “how do you want to do such and such?”

10. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-10 Example Registration Purpose: Register a student for a course Actor: A student Input: A course number Result: The student is registered for the course and an appropriate message is displayed Exception: The student shall not be registered for the course for any of the following reasons, which shall be contained in the output: There exists a prerequisite course that the … etc. etc.

11. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-11 Universal Modeling Language UML Use cases are part of the UML –UML is a graphic language for modeling various static and dynamic aspects of a systems behavior –Provides a set of diagrams, each of which models a different aspect of the system behavior. Because UML is graphic it is particularly appropriate for communicating between the analyst and the customer and between various members of the implementation team

12. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-12 Use Case Diagrams UML provides a graphic way to display all the use cases in an application These diagrams can be used to communicate with the –Customer to determine if the current set of use cases is adequate –Implementors to determine what the system is supposed to do from the customer’s viewpoint

13. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-13 StudentGrade Authentication Register Deregister Student Faculty Member GetGradeHistory GetRegistered Courses GetEnrolled Courses EndOfSession OLAP Query Room GetClassRoster EndOfSemester Course Information Student/Faculty Information Use Case Diagram for the Student Registration System

14. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-14 Issues Frequently while analyzing the Requirements Document to produce the Specification Document, issues arise that must be brought to the attention of the customer and resolved –The Requirements Document might be inconsistent or incomplete in certain areas –It is important to get such issues resolved early in the project, since it becomes increasingly expensive to made changes as the project proceeds

15. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-15 Partial Contents of a Specification Document A picture of every form on the GUI with every control specified A description of what happens when each control is used –What application procedure is executed –What changes in the form occur –What error situations can occur and what happens A description of each interaction with the system –Information input by user –Textual description of what happens –List of conditions under which it succeeds or fails and what happens in each case

16. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-16 Partial Contents of a Specification Document (cont’d) Integrity constraints of the enterprise System issues –Hardware and software used by the system Throughput and response time constraints Project planning information –Milestones –Deliverables –Costs

17. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-17 UML Sequence Diagrams Part of the plan for preparing the Specification Document might be to expand each use case into a UML Sequence Diagram –A graphic display of the temporal ordering of the interactions between the actors in a use case and the other modules in the system

18. 14-18 DatabaseWeb Server Student or Faculty Member Validate Login Return Status Enter URL Display Welcome Page Enter ID & Password Click OK [Status=Student] Display Student Options Page [Status=Faculty] Display Faculty Options [ Page [Status=Error] Display Authentication Error Page [Status=Fail] Click OK [Status=Fail] Display Welcome Page A Sequence Diagram for the Authentication Use Case

19. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-19 Sequence Diagrams The actors and pertinent modules are labelled at the top of the diagram Time moves downward The boxes show when a module or actor is active The horizontal lines show the actions taken by the modules or actors –Note the notation for conditional actions [status=student] Display Student Options Page

20. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 14-20 Specification Document for the Student Registration System Preparing the Specification Document for the Student Registration System is an exercise for the students Initial portions of some sections are given in the text