1 / 18

Requirements Phase

Requirements Phase. Chapter 9. Requirements Phase. What must the new product be able to do? What the client needs?. Requirements. Functional Requirements: describe the interaction between the system and its environment

nolen
Download Presentation

Requirements Phase

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Phase Chapter 9 UHD-CMS-Chp9

  2. Requirements Phase • What must the new product be able to do? • What the client needs? UHD-CMS-Chp9

  3. Requirements • Functional Requirements: describe the interaction between the system and its environment • Environment: users, any other external system with which the system interacts • Non-Functional Requirements: quantitative constrains e.g. • response time • accuracy UHD-CMS-Chp9

  4. Requirements Contd • Pseudo-requirements: requirements imposed by the client that restrict the implementation of the system • implementation language • platform • process and documentation requirements: e.g. use of a specific formal specification language, etc. UHD-CMS-Chp9

  5. Requirement Elicitation • Identify the actors: an actor is an external entity that interacts with the system • Identify scenarios: a scenario is a concrete, focused informal description of a single feature of the system from the viewpoint of a single actor UHD-CMS-Chp9

  6. Questions to identify scenarios • What are the tasks that the actor wants the system to perform • What info does the actor access? • Who creates that data? • Can it be modified or removed? • Which external changes does the actor need to inform the system about? How often? When? • Which event does the actor need to be informed by the system about? UHD-CMS-Chp9

  7. Req. Analysis Techniques • Interviews • Structured • Unstructured • Send a questionnaire • Examine the various forms • Set up video cameras • Scenarios • Rapid Prototyping (most effective) UHD-CMS-Chp9

  8. Rapid Prototyping • Exhibit the key functionality • Reflects the functionality that the client sees • Built quickly • Built to be changed • using 4GL and interpreted languages • Using UNIX Shell or Lisp UHD-CMS-Chp9

  9. Human Factors • Human-computer interface (HCI) • User friendly • using windows, icons, menus, .. • Menu-driven system is thoughtfully designed • multiple level of sophistication • implies reduced learning times and lower error rates • e.g., Macintosh UHD-CMS-Chp9

  10. Rapid Prototyping as a Spec. Tech. • Fully or partially • advantage • offers speed and accuracy • Disadvantages • can not be used as a legal document • maintenance problems • Should be used just for requirement analysis UHD-CMS-Chp9

  11. Reusing the Rapid Prototype • Refine it, until it becomes the product • In theory a fast development process • In practice much like build-and-fix • Reasons for throwing it away • cheaper in both short and long term • performance (specially in real time systems) • to enforce not being reused • build it in a different language • use limited languages (e.g., hypertext) • hybrid approach is used UHD-CMS-Chp9

  12. Other uses for Rapid Prototyping • To resolve disagreements • In many cases the only way to arrive to consensus quickly UHD-CMS-Chp9

  13. Management issues in regard to Rapid Prototyping • Encourage clients for changing the product • Changes be made quickly • Not to wait for the real product • It has not been proved beyond all doubts • two aspects: • used solely for requirement analysis • in special cases could be used as a specification • Rapid Prototyping has no good design • requires interactions unlike waterfall model UHD-CMS-Chp9

  14. Experiences with Rapid Prototyping • Gordon and Bieman report • using published and unpublished case studies • 33 out 39 where successful • choice of languages is not critical • partial retaining is important (larger porj.) • fewer unnecessary features were implemented with it UHD-CMS-Chp9

  15. Joint Application Design (JAD) • A techniques for requirement and specification phases • The client takes an active role in the first two phases • Productivity may increase 20 to 60 percent UHD-CMS-Chp9

  16. Comparison of Req. Analysis Techniques • Interviewing (most important) • using forms • with relevant members of client organization • Rapid Prototyping to meet client’s real needs • using JAD UHD-CMS-Chp9

  17. Case Tools for Req. • Interpreted languages • Case tools and language environments • smalltalk, interlisp, UNIX shell • Hypertext • two popular case tools • Demo II, Guide • 4GL UHD-CMS-Chp9

  18. Metrics for the Req. Phase • Measure of requirement volatility • can be used for scenario and interview techniques • Number of requirements changes during the development process • Number of time each feature is used • useful in Rapid Prototyping UHD-CMS-Chp9

More Related