Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

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

Volere

Project Drivers

1. The Purpose of the Project

2. The Client, the Customer, and Other Stakeholders

3. Users of the Product

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.

5. Naming Conventions and Definitions

6. Relevant Facts and Assumptions

Functional Requirements

7. The Scope of the Work

8. The Scope of the Product

9. Functional and Data Requirements

Non Functional Requirements

10. Look and Feel 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.

12. Performance Requirements

13. Operational and Environmental Requirements

14. Maintainability and Support Requirements

15. Security Requirements

16. Cultural and Political Requirements

17. Legal 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

20. New Problems

21. Tasks

22. Migration to the New Product

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

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.