Req documentation standards
•Download as PPTX, PDF•
0 likes•104 views
Requirements Documentation Standards. Focus on the Volere Template.
Recommended
More Related Content
Similar to Req documentation standards
Similar to Req documentation standards (20)
Recently uploaded
Recently uploaded (20)
Req documentation standards
- 2. Req. Documentation Standards ● A requirements specification document clearly describes the essential requirements of a system. ● It defines the scope and boundaries of the system. ● It forms the basis of a contract between the clients and contractors. ● There are standards that serves as models for requirements documents. ● These standards provide templates that can be used to structure requirements documents 2
- 3. Volere
- 4. Volere Template ● Developed by Suzanne and James Robertson ● Presents a template that may be used to specify user requirements as well as developer requirements ● The first edition of the Volere Requirements Specification Template was released in 1995. ● Since then, organizations from all over the world have saved time and money by using the template as the basis for discovering, organizing, and communicating their requirements. 4
- 5. Volere Template Overview ● The template is set into five main divisions ○ Project Drivers ○ Project Constraints ○ Functional Requirements ○ Non-functional Requirements ○ Project issues 5
- 6. Project Drivers ● These are the factors that caused the project to be undertaken in the first place 1. The Purpose of the Project 2. The Client, the Customer, and the Other Stakeholders 3. Users of the Product 6
- 7. Project Constraints ● These are the issues that have a strong influence on the requirements and the outcome for the product. 4. Mandated constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions 7
- 8. Functional Requirements ● These define the what operations/activities the system is expected to perform 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements 8
- 9. The Volere Shell - Requirements Shell 9
- 10. Non-functional requirements ● These are the properties the product must have. 10. Look and Feel Requirements 11. Usability Requirements 12. Performance Requirements 13. Operational Requirements 14. Maintainability and Portability Requirements 15. Security Requirements 16. Cultural and Political Requirements 17. Legal Requirements 10
- 11. Project Issues ● These are projects concerns brought to light by the requirements activity. 18. Open Issues 19. Off-the-Shelf Solutions 20. New Problems 21. Tasks 22. Migration to new product 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions 11
- 12. Conclusion ● Standards provide means to structure requirements documents. ● Standards indicate what should be the content of a requirements specification. ● Provides means to raise completeness. 12
- 13. References ● Mastering the Requirements Process 2nd Edition. ○ Suzanne Robertson, James Robertson ● www.volere.co.uk 13
Editor's Notes
- Requirements – Functional, non functional, design constraints, quality attributes Elaborated from the eliticatation process results.
- Its not owned an internationally recognized as body such ieee by by two re researchers with the help of a lot of other professionals Defines a requirements engineering process model One of the results - Produced a template for requirements documentation
- ALSO developed a process model
- Fundamental Reason the clients asked for the product Stakeholders – people who have interest –client who pays, customer who buys, developers, testers, proj, manager Users directly interact with product
- Constraints are global, factors that apply to the entire product, usually determined by mgmt. Restrict what you can do, e.g budget constraints All project have unique vocabulary, acronyms, avoid misunderstanding/miscommunication Facts are external factors that affect the product,assumptions being made by the project team. Project constraints and project drivers set the scene for the requirements to follow
- Set Boundaries of the business area Set product boundaries – use cases
- Shells –guide to construct Req no – unique Req type –volere pre-specified req types –func req 9, usability 11, look and feel – 10 Originator raised the req Fit criterion is a quantified goal the solution has to meet. Acceptance criterion History – can add names of persons
- Product apperance, easy to use, secure, laws that apply, built into the product but not part of its functionality We also use the shell with non-func reqs
- Unanswered questions around user business, stakeholders might be unsure of how the work should be done in the future Ready made components that can be used Changes to existing order bring effects Steps to be taken to deliver the product Before install new product, some work has to be done beforehand, parallel running All projects involve risk Cost -money/effort Waiting room – req. That cannot be part of the initial release Ideas for implementation
- Complete They should include descriptions of all facilities required. Consistent There should be no conflicts or contradictions in the descriptions of the system facilities.