-
Notifications
You must be signed in to change notification settings - Fork 28
Artifacts
A vision statement for your project. Describe ideas in Wiki style syntax with this artifact.
You should use vision statement to describe the basic purpose of your project. A vision should be clear and simple so that everbody is able to understand the basic purpose the project. [Alexander 2009, p. 53]
Workareas are used to structure a couple of tasks.
Processwords are needed for the use of a syntactic requirements template. You can define synonyms for the word here and deliver a proper definition of the term.
Use rationals to justify your requirements or other artifacts.
Descisions on requirements and design are often based on hidden assumptions. Making assumptions explicit through a rationale enables decisions to be revised. Rationales also help to prioritize requirements and protect them from being removed.
For managing the most important RE artifact.
Deriving requirements from scenarios helps to prevent you from inventing requirements because these artefacts should be the basis for all requirements. You can obtain new requirements from individual stakeholders with the help of interviews and observation. Workshops are the best options for discovering requirements from groups. [Pohl 2008, p. 183], [Alexander 2009, p.260, p. 315]
Managing scenarios to show processes in your system.
If you are unfamiliar with using Lauesens Task-Based aproach for RE - it
is very similiar to the famouse Use-Cases by Cockburn - simply check his
website.
Most important is that you recognize the demand solution prinziple
coming with the two columns of the approach.
Tasks do not distinguish between who does what. Task closure means that your task has a well defined start and end point. A good starting point is something that happens in the user''s world, for instance that a client calls. A good end point is that nothing more can be done about the case right now - the user deserves a "coffee break". [Lauesen 2011, p. 34]
You may want to use goals as high level requirements or to structure your requirements. There are also approaches using goals for the whole RE, especially for understanding the requirements.
Goals are a good starting point to record the intentions of your stakeholders. Goals do not have to be fully achieveable nor measureable. Goals can be regarded as a first sketch of the requirements. You can use goals to discover conflicts between the intentions of your stakeholders and solve this conflicts. This may helps you to establish an overall agreement between your stakeholders. You should take care about that a goal refines a vision statements. [Alexander 2009, p. 51]
Use sections to structure your requirements in the tree to the left.
You should structure your requirements in sections because this helps you to keep all your artefacts and their context-information manageable. There exist a lot of reference structures for requirements. For example you can use the IEEE Standard 1233-1998 which defines a structure for a system requirement specification (SyRS) or the IEEE Standard 830-1998 which defines a structure for a software requirements specification (SRS).
Use Case template as found in Cockburns Book Writing effective Use-Cases.
You can use user profiles to describe your users. They are also used as primary and secondary actors for use cases.
Describing the stakeholder with user profiles is are very important because all requirements come from people. Thus you should discover and document all stakeholder which are involved in your project. [Alexander 2009, p. 28]