Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Volere by Mind Map: Volere
0.0 stars - reviews range from 0 to 5


Project Drivers

1. The Purpose of the Project

1a. The User Business or Background of the Project Effort

1b. Goals of the Project

2. The Client, the Customer, and Other Stakeholders

2a. The Client

2b. The Customer

2c. Other Stakeholders

3. Users of the Product

3a. The Hands-On Users of the Product

3b. Priorities Assigned to Users

3c. User Participation

3d. Maintenance Users and Service Technicians

Project Constraints

4. Mandated Constraints

This section describes constraints on the eventual design of the product. They are the same as other requirements except that constraints are mandated, usually at the beginning of the project. Constraints have a description, rationale, and fit criterion, and generally are written in the same format as functional and nonfunctional requirements.

4a. Solution Constraints

4b. Implementation Environment of the Current System

4c. Partner or Collaborative Applications

4d. Off-the-Shelf Software

4e. Anticipated Workplace Environment

4f. Schedule Constraints

4g. Budget Constraints

5. Naming Conventions and Definitions

5a. Definitions of All Terms, Including Acronyms, Used in the Project

5b. Data Dictionary for Any Included Models

6. Relevant Facts and Assumptions

6a. Facts

6b. Assumptions

Functional Requirements

7. The Scope of the Work

7a. The Current Situation

7b. The Context of the Work

7c. Work Partitioning

8. The Scope of the Product

8a. Product Boundary

8b. Product Use Case List

8c. Individual Product Use Cases

9. Functional and Data Requirements

9a. Functional Requirements

9b. Data Requirements

Non Functional Requirements

10. Look and Feel Requirements

10a. Appearance Requirements

10b. Style Requirements

11. Usability and Humanity Requirements

This section is concerned with requirements that make the product usable and ergonomically acceptable to its hands-on users.

11a. Ease of Use Requirements

11b. Personalization and Internationalization Requirements

11c. Learning Requirements

11d. Understandability and Politeness Requirements

11e. Accessibility Requirements

12. Performance Requirements

12a. Speed and Latency Requirements

12b. Safety-Critical Requirements

12c. Precision or Accuracy Requirements

12d. Reliability and Availability Requirements

12e. Robustness or Fault-Tolerance Requirements

12f. Capacity Requirements

12g. Scalability or Extensibility Requirements

12h. Longevity Requirements

13. Operational and Environmental Requirements

13a. Expected Physical Environment

13b. Requirements for Interfacing with Adjacent Systems

13c. Productization Requirements

13d. Release Requirements

14. Maintainability and Support Requirements

14a. Maintenance Requirements

14b. Supportability Requirements

14c. Adaptability Requirements

15. Security Requirements

15a. Access Requirements

15b. Integrity Requirements

15c. Privacy Requirements

15d. Audit Requirements

15e. Immunity Requirements

16. Cultural and Political Requirements

16a. Cultural Requirements

16b. Political Requirements

17. Legal Requirements

17a. Compliance Requirements

17b. Standards Requirements

Project Issues

18. Open Issues

Issues that have been raised and do not yet have a conclusion. Content A statement of factors that are uncertain and might make significant difference to the product. Motivation To bring uncertainty out in the open and provide objective input to risk analysis. Examples Our investigation into whether the new version of the processor will be suitable for our application is not yet complete. The government is planning to change the rules about who is responsible for gritting the motorways, but we do not know what those changes might be. Considerations Are there any issues that have come up from the requirements gathering that have not yet been resolved? Have you heard of any changes that might occur in the other organizations or systems on your context diagram? Are there any legislative changes that might affect your system? Are there any rumors about your hardware or software suppliers that might have an impact?

19. Off-the-Shelf Solutions

19a. Ready-Made Products

19b. Reusable Components

19c. Products That Can Be Copied

20. New Problems

20a. Effects on the Current Environment

20b. Effects on the Installed Systems

20c. Potential User Problems

20d. Limitations in the Anticipated Implementation Environment That May Inhibit the New Product

20e. Follow-Up Problems

21. Tasks

21a. Project Planning

21b. Planning of the Development Phases

22. Migration to the New Product

22a. Requirements for Migration to the New Product

22b. Data That Has to Be Modified or Translated for the New System

23. Risks

All projects involve risk—namely, the risk that something will go wrong. Risk is not necessarily a bad thing, as no progress is made without taking some risk. However, there is a difference between unmanaged risk—say, shooting dice at a craps table—and managed risk, where the probabilities are well understood and contingency plans are made. Risk is only a bad thing if the risks are ignored and they become problems. Risk management entails assessing which risks are most likely to apply to the project, deciding a course of action if they become problems, and monitoring projects to give early warnings of risks becoming problems. This section of your specification should contain a list of the most likely risks and the most serious risks for your project. For each risk, include the probability of that risk becoming a problem. Capers Jones’s Assessment and Control of Software Risks (Prentice-Hall, Englewood Cliffs, N.J., 1994) gives comprehensive lists of risks and their probabilities; you can use these lists as a starting point. For example, Jones cites the following risks as being the most serious: • Inaccurate metrics • Inadequate measurement • Excessive schedule pressure • Management malpractice • Inaccurate cost estimating • Silver bullet syndrome • Creeping user requirements • Low quality • Low productivity • Cancelled projects Use your knowledge of the requirements as input to discover which risks are most relevant to your project. It is also useful input to project management if you include the impact on the schedule, or the cost, if the risk does become a problem.

24. Costs

For details on how to estimate requirements effort and costs, refer to Appendix C Function Point Counting: A Simplified Introduction The other cost of requirements is the amount of money or effort that you have to spend building them into a product. Once the requirements specification is complete, you can use one of the estimating methods to assess the cost, expressing the result as a monetary amount or time to build. There is no best method to use when estimating. Keep in mind, however, that your estimates should be based on some tangible, countable artifact. If you are using this template, then, as a result of doing the work of requirements specification, you are producing many measurable deliverables. For example: ● Number of input and output flows on the work context ● Number of business events ● Number of product use cases ● Number of functional requirements ● Number of nonfunctional requirements ● Number of requirements constraints ● Number of function points The more detailed the work you do on your requirements, the more accurate your deliverables will be. Your cost estimate is the amount of resources you estimate each type of deliverable will take to produce within your environment. You can create some very early cost estimates based on the work context. At that stage, your knowledge of the work will be general, and you should reflect this vagueness by making the cost estimate a range rather than a single figure. As you increase your knowledge of the requirements, we suggest you try using function point counting—not because it is an inherently superior method, but because it is so widely accepted. So much is known about function point counting that it is possible to make easy comparisons with other products and other installations’ productivity. It is important that your client be told at this stage what the product is likely to cost. You usually express this amount as the total cost to complete the product, but you may also find it advantageous to point out the cost of the requirements effort, or the costs of individual requirements. Whatever you do, do not leave the costs in the lap of hysterical optimism. Make sure that this section includes meaningful numbers based on tangible deliverables.

25. User Documentation and Training

25a. User Documentation Requirements

25b. Training Requirements

26. Waiting Room

Requirements that will not be part of the next release. These requirements might be included in future releases of the product. Content Any type of requirement. Motivation To allow requirements to be gathered, even though they cannot be part of the current development. To ensure that good ideas are not lost. Considerations The requirements-gathering process often throws up requirements that are beyond the sophistication of, or time allowed for, the current release of the product. This section holds these requirements in waiting. The intention is to avoid stifling the creativity of your users and clients, by using a repository to retain future requirements. You are also managing expectations by making it clear that you take these requirements seriously, although they will not be part of the agreed-upon product. Many people use the waiting room as a way of planning future versions of the product. Each requirement in the waiting room is tagged with its intended version number. As a requirement progresses closer to implementation, then you can spend more time on it and add details such as the cost and benefit attached to that requirement. You might also prioritize the contents of your waiting room. “Low-hanging fruit”—requirements that provide a high benefit at a low cost of implementation—are the highest-ranking candidates for the next release. You would also give a high waiting room rank to requirements for which there is a pent-up demand.

27. Ideas for Solutions

When you gather requirements, you focus on finding out what the real requirements are and try to avoid coming up with solutions. However, when creative people start to think about a problem, they always generate ideas about potential solutions. This section of the template is a place to put those ideas so that you do not forget them and so that you can separate them from the real business requirements. Content Any idea for a solution that you think is worth keeping for future consideration. This can take the form of rough notes, sketches, pointers to other documents, pointers to people, pointers to existing products, and so on. The aim is to capture, with the least amount of effort, an idea that you can return to later. Motivation To make sure that good ideas are not lost. To help you separate requirements from solutions. Considerations While you are gathering requirements, you will inevitably have solution ideas; this section offers a way to capture them. Bear in mind that this section will not necessarily be included in every document that you publish.