2. Fundamental principles of requirements engineering Flashcards
Task
a coherent chunk of work to be done
Activity
an action or a set of actions that a person or group performs to accomplish a task
Practice
a proven way of how to carry out certain types of tasks or activities
Nine fundamental principles
- Value orientation
- Stakeholders
- Shared understanding
- Context
- Problem, requirement, solution
- Validation
- Evolution
- Innovation
- Systematic and disciplined work
- Value orientation
Requirements are means to an end not an end in itself.
NB benefits of RE are long-term whereas the costs are immediate
Benefit of a requirement
is a degree to which it contributes to building successful systems (systems that satisfy the desires and needs of stakeholders) and to reducing the risk of failure and costly rework in system development.
Economic value of RE is indirect - saves costs
Cost of requirements
cost of eliciting, validating, documentating and managing it
Influencing factors on the amount of RE
Criticality of requirement can be assessed in terms of
- importance to stakeholders
- impact of missing the requirements
- effort needed to specify
- distinctiveness of requirement
- degree of shared understanding between stakeholders
- existence of reference system (examples)
- length of feedback cycle
- kind of customer supplier relationship
- regulatory compliance required
NB effort invested shall be inversely proportional to the risk.
Core goals of RE
understanding stakeholder’s desires and needs and minimising the risk of delivering a system that does not meet these desires and needs
Stakeholder
- every stakeholder has a role in the context of the system to be built
Persona
fictitious character that represents a group of users with similar characteristics
used for stakeholder roles with to many individuals or when individuals are unknown
Stakeholder classification by influence
- Critical
- Major
- Minor
Useful for resolving conflicts between requirements and prioritising
Critical stakeholder
not considering these stakeholders will result in severe problems and make the system fail or render it useless
Major stakeholder
not considering these stakeholders will have an adverse impact on the success of the system but not make it fail
Minor
not considering these stakeholders will have no or minor influence on the success of the system
Forms of shared understanding
- explicit shared understanding
- implicit shared understanding
NB both can be false, concentrate about relevant things
Explicit shared understanding
achieved through carefully elicited, documented and agreed requirements.
Implicit shared understanding
based on shared knowledge about needs, visions, context, e.c.t.
Enablers of shared understanding
- domain knowledge
- domain-specific standards
- previous successful collaboration
- existence of reference systems known by all people involved
- shared culture and values
- informed mutual trust
Obstacles for shared understanding
- geographical distance
- supplier-customer relationship guided by mutual distrust
- outsourcing
- regulatory constraints
- large and diverse teams
- high turnover among people involved
Context (in RE)
part of a system’s environment being relevant for understanding the system and its requirements
Entities in the context will somehow influence the system or even interact with it but will not be contained in the system itself
Context boundary
boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements
System boundary
boundary between the system and surrounding context
Scope of system development
the range of things that can be shaped and designed when developing a system
Not always the same as the system boundaryD
Domain assumptions
assumptions about real-world phenomena in the context of a system
- Problems, requirements and solutions
inevitably intervened.
no sense to create requirements if there is no problem to solve or no solution to be developed
- Validation
Non-validated requirements are useless.
Validation
the process of confirming that am item matches stakeholders needs
Things to validate
- Agreement about the requirements has been achieved among stakeholders (conflicts resolved, priorities set)
- Stakeholder’s desires and needs are adequately covered by the requirements
- The domain assumptions are reasonable
- Evolution
Changing requirements are no accident, it is normal.
enabling change while preserving stability
Reasons for changing requirements
- Change business process
- Competitors launching new products or services
- Clients change priority and opinions
- Changing in technology
- Feedback from system users asking for new or changed feature
- Detection of errors in requirements or detection of faulty domain assumptions
- Systematic and disciplined work
A systematic and disciplined approach to RE improves the quality of a system
No one-size fits all in RES
Systematic and disciplined RE
- Configure RE that is well suited for the problem at hand and fits development process
- Select appropriate RE practices and work products available based on the environment
- Do not always use same process, practices and Was
- Do not reuse practices from past successful RE works without reflection
- Innovation
Good requirements engineers are innovation aware, strive for exciting new features, look at big picture
Do not assume you know everything better than the stakeholder
- Stakeholders
RE is about satisfying the stakeholders’ desires and needs
- Shared understanding
Successful systems development is impossible without a common basis
- Context
Systems cannot be understood in isolation
