What are the elements of a usable requirements specification for a software solution?
- Scope: What organizational units, firms and companies are affected?
- Initial situation: actual state, unsatisfying points.
- Common goals and expected benefit (e.g. save time, error reduction, faster processing, faster search, added customer value, less learning effort)
- General requirements on the intelligence of the solution: Shall the intelligence lay with the user or in the application?
- Expected ROI (Return on Investment): Can the ROI be calculated roughly for the solution? Which savings are possible and in what timeframe can they be realized?
- User groups: Who are the future users? Locations? Description of user roles: Which organizational roles do these users have?
- Description of business cases resp. use cases: case description, activity description, flow charts or scenarios.
- Description of mapped forms and documents (examples attached in paper form or as file).
- Quantity structure and capacity: Number of users, number of existing and new documents/data sets per type and year, average size of documents/data sets
- State system: Which states may occur?
- Primary Keys: On the basis of what criteria can the data sets be distinguished?
- Access authorization: Who should have reader access? Who is allowed to change documents? Who is the application's administrator and is allowed to change parameter settings?
- Interfaces to other systems: Which data should periodically be imported or exported? How often? What is the source media? What is the goal?
- Print-out: What are the requirements for printing?
- Data migration: Is there a unique resp. first-time data import to do? For which data? Which is the source system?
- Risk analysis: What are the risks in this project? Which countermeasures are available?
- Checklist for user-tests: It makes sense to describe the future tests already in the requirement specification because they also serve as default. ATEGRA is happy to provide you with an example test-plan.
Good requirements specifications specify not the solution but the requirements. The outcome of this is also that there shouldn’t be any hardware or software specifications contained in the requirements specification – with one exception: If there are any technological boundary conditions which have to be fulfilled. In any case it is good practice if the users describe the requirements specifications and the computer experts the solution – and not the other way around.
The requirements specifications should primary be written by a user so that the user view be reflected. The requirements specifications should be preferably created without technical in-house IT people. They should not be involved until the software development starts, so the stage of problem description and the stage of solution implementation can be separated clearly. This forces us to make the requirements specifications technology-neutral. It is meaningful that the users describe the problems all-embracing and correct, and leave the problem solution to the computer scientists. A good requirements specification doesn’t describe the solution but the needs.
A good requirements specification is compact, consistent and comprehensible formulated. It makes sense to include those persons which have a lot of experience with the subject of requirements specification. It is also recommended to have at least one person in the team who has a lot of experience in the area of analysis. That person can be used as co-author or reviewer. Either you find such a person in your organization or ATEGRA will provide you with a qualified specialist.
We will support you in the development of the requirements specifications for a new software solution.
EA big problem in practice is that a lot of requirements specifications are difficult to understand. It may also often occur that the requirements specifications are not complete, that important requirements are not covered which will be brought forward later on and cause significant follow-up costs.
Goal of our work is a requirements specification that
- describes all essential requirements
- is consistent
- is simple, comprehensible and clearly describes the problem
- is approved by the most important users
- contains all necessary information for the computer scientists and their following design of the solution
There several different approaches for the development of a requirements specification:
We elaborate the requirements alltogether. The design of the masks belongs also to the topics in the workshop. Masks are an excellent basis for the communication and discussion between user and computer experts. We develop and describe the masks together. Many times they correspond to already existing forms available in paper form or as Word or Excel file. In the workshop discussions we often discover important details e.g. when discussing the status system or the different types. Byproduct is the data model. The data model is as well important for the software-developers as for an architect the plan of the house to be built. A good data model may be used many years and creates a stable basis for later changes. We also define the different user groups and their roles, specify their access levels (who is allowed to see which data and who is allowed to make changes?).
We interview a representative selection of future users and try to get to know their wishes and requirements. It is often the point to understand with what software tools the users work today and how reasonable it is to introduce therefore a new software solution. A positive side effect of such interviews is an increasing acceptance, because the users appreciate it when they are asked about their opinion and requirements.
The software engineers of ATEGRA have developed a new model: HR Solutions read more
ATEGRA offers you tailor-made software solutions for idea management read more
Solutions for the handling of e-mail and other electronic documents read more
