1 / 11

Chapter 7: Other Requirements

Chapter 7: Other Requirements. 7.1. Introduction. Recall: in the UP requirements are categorised according to the FURPS+ model: Functional : features; Usability : human factors, help, documentation; Reliability : frequency of failure, recoverability;

euphemia
Télécharger la présentation

Chapter 7: 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. Chapter 7: Other Requirements

  2. 7.1. Introduction • Recall: in the UP requirements are categorised according to the FURPS+ model: • Functional : features; • Usability : human factors, help, documentation; • Reliability : frequency of failure, recoverability; • Performance : response times, throughput, resource usage; • Supportability : adaptability, maintainability, internationalisation; • in addition the the ‘+’ in FURPS+ indicates ancillary requirements or constraints such as: • Implementation : language and tools, hardware restrictions; • Interface : interfacing constraints; • Packaging : physical box; • Legal : licensing;

  3. While use cases are good for the ‘F’ in FURPS+, they are not the full story… • Typical additional artifacts may include: • The Supplementary Specification captures and identifies other kinds of requirements, such as art work, tentative GUI screenshots, target platform, prototypes, scripts (dialogue), storyboards (scenes), packaging, merchandising, supportability, licensing, market analysis, and so forth. • The Glossary captures terms and definitions; it can also play the role of a data dictionary. • The Vision summarizes the "vision" of the project; an executive summary. It serves to tersely communicate the big ideas. • The Business Rules (or Domain Rules) capture long-living and spanning rules or policies, such as game rules, network protocol specification, security constraints, that transcend one particular application.

  4. 7.2 During Inception • Remembering that we use the UP, an iterative process, the additional artifacts need not be fully detailed before production-quality design, coding and testing takes place. • This allows feedback that can enhance, clarify and complete the requirements … • So we may draft some aspects of the additional requirements documents knowing full well that they will change and grow overtime.

  5. 7.3 POS Supplementary Specification • See separate document • This is only a sample document… • Any specific functional requirement specific to a use case should really be detailed in the concerned use case, but all non-functional requirements should be in the supplementary specification document. • The supplementary specification is concerned with FURPS: • Functional, Usability, Reliability, Performance, Supportability and the ‘+’ …

  6. 7.4 POS Vision • See separate document • The vision document should not be long. • It should summarise some of the information from use cases and supplementary specification. • The Summary of Features is complementary (to use cases), terse, way of summarising what will the software offer to all users. Not too much details is required : just a summary of the main functionalities as detailed in the use cases…

  7. 7.5 POS Glossary • See separate document • Used to ensure developers use the same terminology throughout a project. • Only start one if there is a clear need for it.

  8. 7.6 POS Business Rules • AKA Domain rules. • May include government rules (legislation), detailed game rules (e.g. chess, card games etc.).

  9. 7.7 Evolutionary Requirements in Iterative Processes • Remember that all the requirements (use cases as well) are not fully analyzed and written near the start of the project: they are allowed to evolve after feedback… • During inception for example one goal is to decide whether the project is worth of further investment (carried out during the elaboration phase): so most use cases will not be detailed, the supplementary specification could be only lightly developed (only trying to identify risk areas for example). The same applies to the vision document. • During Elaboration the vision can be refined, use cases can be detailed, and the supplementary specification completed. • During construction, only minor changes should be entertained in all the requirements documents.

  10. 7.8 Conclusion • As we use an agile evolutionary process, we must keep in mind that the specification documents are never really frozen (changes are to be welcomed), and that we do not expect a full detailed specification after the inception phase. • Nevertheless, we must avoid the trap of having to redo (or change significantly) completely the requirement documents …: • While we accept that the documents are likely to be changed and can be incomplete initially we must be able to identify the most important requirements during inception. • The subsequent phases should only complete and refine these documents. • A complete rewrite later in the project may have disastrous consequences for the project…

  11. Discovering, documenting and refining requirements is mostly a people activity: all stakeholders must be involved in their elicitation: • Team building is necessary ; • Communication techniques, workshops, brainstorming are all parts of this process. Resources • http://readyset.tigris.org/ offers templates for frequently used artifacts including requirement documents.

More Related