Overview of some aspects:
- Goals
- Natural language requirements
- Analysis model
- Acceptance Criteria
- Simulation model (Prototype)
Goals
A system can only be developed successfully if its goals are clearly defined. Goals are requirements on a high level of abstraction, and they are subject to the same quality criteria as all other requirements. Evaluating goalss does not only mean documenting them, but also comparing them to each other and, furthermore, documenting the constraints known. The elicitation of goals already bears the need to know the system´s stakeholders. A list of stakeholders as complete as possible offers a great starting point for all following activities.
In our download area you will find a stakeholders checklist. For an exchange of experiences on how to foster stakeholders we consultants will always be at your service.
Natural language requirements
The main part of Object Engineering is natural language requirements. Natural language is the most common means for the documentation of requirements. However, requirements written in prose can only be properly used within the development process when they meet certain demands. Therefore, a process model should provide the persons writing requirements with defined rules.
As there has been no standard for the creation of natural language requirements established within IT, Object Engineering offers rules like the SOPHIST set of REgulations and various patterns. These approaches can assist you, but they are not obliging.
See our download area for the one and only SOPHIST set of REgulations. (only available in German)
Analysis model
An analysis model makes it easier to understand the usually very complex correlations between requirements.
As the model is presented graphically, it can also be a kind of scaffolding, helping to sort and find single requirements. The analysis model integrates the requirements in one model and thus depicts requirements related to the same subject in the same element of the model - no matter how scattered these requirements are within the requirements specification. Another advantage is that contradictions and redundancies can be systematically discovered.
Acceptance criteria
Acceptance criteria define the conditions for the decision whether a certain requirement is fulfilled or not.
On the one hand, acceptance criteria are a means to evaluate the results of the analysis. On the other hand, they provide the basis for the acceptance of the final product. Acceptance criteria check the completeness of requirements and specify specific examples of abstract requirements. Thus, they minimize the risk of misinterpretation and increase the understandability of requirements. It makes sense to include a person with experience in testing in the preparation of acceptance criteria.
Simulation Model (Prototype)
When missing functionalities are only discovered when the system is in practical use, you can be sure that necessary requirements were missing. However, then it is too late to change or add functionalities: The system development is done.
The requirements for a system have to be elicited and documented on the basis of the stakeholders’ ideas, hence when the system is not yet developed. Good means to make these ideas as specific as possible are prototypes. A prototype is always an implementation or realization of one part of the system to be developed.
An accurate analysis of the project’s risks is necessary in order to decide which ones out of all the methods available are the ones suiting your problem. Read our project reports (only availabel in German!) to get an idea.