1 / 17

Other Requirements

Other Requirements. Chapter 7 Applying UML and Patterns Craig Larman. Introduction. Primary requirements of computer systems tend to be functional requirements the list of activities that the system must perform to provide value to its users

truman
Download Presentation

Other Requirements

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. Other Requirements Chapter 7 Applying UML and Patterns Craig Larman

  2. Introduction • Primary requirements of computer systems tend to be functional requirements • the list of activities that the system must perform to provide value to its users • Developers must also capture other non-functional system requirements • Non-functional requirements may be captured in: • Vision Statement • Glossary • Supplementary Specification.

  3. Non-Functional Requirements Are Not a Checklist • Not a listing of things that have to be documented in a system • Documentation costs money and takes time. • Use only enough resources to produce the desired results efficiently and effectively.

  4. Vision Statement • Communicates the project sponsor’s and key stakeholder’s… • reasons for the project • problems to be solved • description of stakeholders and their needs • description of the proposed solution • Vision Statement contains the core system requirements • It becomes the contractual basis to develop further requirements

  5. Glossary • Captures terms and their definitions in the business domain • Terms may mean different things to different stakeholders and need to be defined. • Can also perform the role of a Data Dictionary, or be supplemented by one. • See example p. 115 in textbook

  6. Supplementary Specification • Captures requirements such as documentation, supportability, packaging, licensing.

  7. Supplementary Specification Contents • Common Functionality • Logging • Error Handling • Business Rules • Security • Usability • Reliability • Recoverability • Performance • Supportability • Adaptability • Configurability • Implementation Constraints • Purchased Components

  8. More Supplementary Specifications • Interfaces • Hardware • Software • Domain Rules • Legal Issues • Reports • Operating Systems • Networking Systems • Process Tools • Development Tools • Design Constraints • Internationalization • Standards • Physical Environment • Operation Rules

  9. Domain or Business Rules • Are not functional requirements. • Describe how the business works, while functional requirements tell how the system works. • Company policies and government regulations are examples

  10. UML Diagrams in Inception • Aside from the possible inclusion of a few high level use case diagrams, the inception phase is almost all text. • Most diagramming occurs in the Elaboration Phase.

  11. From Inception to Elaboration Chapter 8 Applying UML and Patterns Craig Larman

  12. Inception - Artifacts and Activities • Requirements workshop • Name actors, goals, use cases • Keep use cases brief • Identify most risky & influential quality requirements • First version of Supplementary Specification and Vision Statement

  13. Inception - Artifacts and Activities • Risk list • Technical feasibility • UI oriented prototypes • Buy/build/reuse components • High-level candidate architecture • Plan first iteration • Candidate tools list

  14. Elaboration - Key Ideas • Not a waterfall model ! • Two to six weeks for each iteration • Timeboxed iterations • Each iteration ends in a stable and tested release

  15. Best Practices • Start programming early • Adapt based on feedback • Design, implement, and test adaptively • Test early and realistically • Determine requirements and use case details through a series of workshops

  16. UP Elaboration Artifacts • Domain Model – visualization of domain concepts and relationships • Design Model – diagrams of logical design • (e.g. software class and package diagrams) • Software Architecture Document – summary of key architectural issues • Data Model – database schemas and relational/object mapping strategies • UI Prototypes – user interface

  17. Elaboration “Fails” When… • No Timeboxed schedule - only one Iteration • No Risk mitigation/resolution • No Executable Architecture • Minimal feedback and adaptation • No early and realistic testing • No Proof-of-concept programming

More Related