Processes Flashcards
Explicit versus implicit RE
RE as an implicit task
* “It is the code that counts”
* Clarify requirements during development
RE as an explicit task
* Requirements must be clarified by the responsible
persons so thoroughly that no decisions related to
the requirements are made by programmers during
the implementation
What is an engineering model?
An engineering model describes systematic, engineering-like and quantifiable procedures to solve
tasks of a certain class in a repeatable way
Sub models:
role, activity, artifact/product, process model
Role model and process model
Process model: Instantiation at the beginning of the project defines milestones
Role model:
* Roles have explicit skills and the responsibility for
an artifact
* Example are:
− Business analyst as domain expert
− Requirements Engineer as mediator between
context areas and development
− System Architect
* Roles can be filled by different people or by the
same person in personal union
Engineering Models: two types
Activity-orientation:
* Focus on the activities
performed
* Specifies who does what in
which way and at what time
Artifact-orientation:
Focus on what is created and its
characteristics
* Defines responsibilities per
artifact
Activity-oriented approach: adv and disadv
adv:
Description of the work process
Specification of a temporal order and
detailed instructions for action
disadv:
Restrictive: This way and only this way!
Complex planning, difficult to measure the
quality of the results
No statements about artifact contents and
dependencies
Artifact-oriented approach: adv and disadv
Adv:
Awareness of clear result structures
(content, dependencies, terminology)
Testable quality and progress control
Clear roles and responsibilities
Good adaptability
Disadv:
High learning curve (thinking in processes
is habitual behavior)
Definition & selection of adequate methods
Derivation of plans complex
Artifact model
all artifacts and dependencies relevant in the process
can be constructed and displayed in different ways
artifact: documents results of development process steps
artifacts and agile
Agile development procedure skeptical about number and level of detail of artifacts beyond code and
tests: no immediate customer value; hard to maintain over time
Artifacts need to be synchronized with each other
artifact model: adv and disadv
- Advantages:
− Flexibility in the process and freedom for creativity and use of discretionary powers in the procedure
− Precise, testable artifacts/specifications
− Clear terminology across project boundaries - Disadvantages:
− Artefact orientation requires learning curves
− The choice of notation/models is essential for the creation of artifacts
− Artifacts and agility
AMDiRE artifact model, : Roles and Layers
Artefact Model for Domain-independent RE
business analysts _> problem -> context layer
req. engineer -> requirements -> requirements layer
system architect -> solution -> system layer
problem and solution space
Problem
- Capture stakeholders and their goals
- Understand and describe the problem
- Specify and validate characteristics and capabilities of potential
solutions
Solution
Iteratively derive a specification of a solution, that solves the problem
- Develop function and architecture models
- Establish tracking and verification
- Incorporate changes
A Note on Refinement and Dependence on the Perspective
The idea is to think about problems, refine them, then start thinking about solutions, then refine them.
But: When thinking about the refinement of a higher-level solution, this higher-level solution may be
considered a problem!
Example:
Problem is to make many people enter a zoo and pay for it
Potential solution is a turnstyle
Problem then is, how to make sure that 120 people per hour can enter
Solution is, use NFC-based tokens
