What is a work product
A recorded intermediate of final product generated in a work processs
A synonym is “artifact”
What are the 5 facets that characterize work products
Purpose, size, representation, lifespan, storage
What are the main representations of work products
- Natural language
- Templates
- Models
Additional
- Drawing
- Prototypes
What are the three categories of lifespan for work products
- Temporary
- evolving
- durable
What are the 6 most important factors that impact the level of details of the requirement
- Problem and project context - the harder the proble and the less familiar the Re and developers are with the project context, the more detail is necessary
- The degree of shared understanding of the problem
- The degree of freedom left to designer and programmers
- Availability of rapid stakeholder feedback during design and implementation
- Cost vs value of a detailed specification
- Standards and regulations
What are the 3 major aspects of functional requirements
- Structure and data
- Function and flow
- State and behavior
Which iso standard can be used as a checklist for quality requirements
ISO 25010 defines a quality model that can be used as a checklist
What are the 5 aspect, performance requirements deal with
- Time (e.g. performing a task or reacting to external events)
- Volume (e.g. required database size)
- Frequency (e.g. of computing a function)
- Throughput (e.g. data transmission or transaction rates)
- Resource consumption (e.g. CPU, storage, bandwidth, …)
When do qualitative representations of quality requirements are enough
- There is sufficient implicit shared understanding
- Stakeholders, requirements engineers, developers agree on a known solution that satisfies the requirements
- Stakeholders only want to give general quality directions and trust the developers to get the details right
- Short feedback loops are in place such that problems can be detected early
What are the categories of constraints to specify
- Technical
- Legal
- Organizational
- Cultural
- Environmental
- Physical
- Particular solutions or restrictions demanded by important stakeholders
What is covered by the context and boundary aspect
Domain requirements and domain assumptions in the context of the system as well as the external actor and the external interfaces between the system and its environments at the system boundary.
As a summary, which aspects must be considered when document requirements
Funtionality (structure and date, function and flow, state and behavior)
Quality
Constraints
Surrounding context (context and boundary)
What are the guidelines to follow when creating RE work products
- Select a work product that fits the intended purpose
- Avoid redundancy by referencing content instead of repeating it
- Avoid inconsistencies between work products, particularly when they cover different aspects
- Use terms consistently, as defined in the glossary
- Structure work products appropriately
Why define a work product plan
- Helps in the planning of efforts and resources
- Ensures that appropriate notations are used
- Ensures that all results are recorded in the right work products
- Ensures that no major reshuffling of information and “final editing” is needed
- Helps to avoid redundancy, resulting in less work and easier maintainability
What are the five recommendations/rules when writing requirements in natural language
- Write short and well-structured sentences
- Create well-structured work products
- Define and consistently use a uniform terminology
- Avoid using vague or ambiguous terms or phrases
- Know and avoid the pitfalls of technical writing
What are the 4 common pitfalls when writing technical documents
- Incomplete descriptions (all placeholders of a verb must be always specified - who gives what to whom)
- Unspecific nouns like the data or the user
- Incomplete conditions (do not focus only on the normal case, specify exceptions)
- Incomplete comparisons
What are the other 3 potential pitfalls when writing technical documents
- Passive voice (as it may hide who is responsible for the action)
- Universal quantifiers (all, always, never)
- Nominalizations (as it may hide unspecified requirements.)
What is the structure of the uniform template for individual requirements defined in ISO29148
[<Condition>]<Subject> <Action> <Objects> [<Restriction>]</Restriction></Objects></Action></Subject></Condition>
Ex.: When a valid card is sensed, the system shall display the “Enter your pin” message on the dialog screen within 200 ms
Explain shall, should, may, will signification when formulating an action
- Shall -> mandatory requirement
- Should -> a requirement that is not mandatory but strongly desired
- May -> suggestion
- Will (or a verb in the present tense) denotes a factual statement that is not considered as a requirement
Phrase template for ubiquitous requirements
The <system> shall <system></system></system>
Event-driven requirement phrase template
WHEN <optional> <trigger> the <system> shall <system></system></system></trigger></optional>
Unwanted behavior phrase template
IF <option> <trigger>, THEN the <system> shall <system></system></system></trigger></option>
State-driven requirements (apply only in certain states) phrase template
WHILE <in> the <system> shall <system></system></system></in>
Optional features phrase template
WHERE <feature>, the <system> shall <system></system></system></feature>
