5. Process and working structure Flashcards
Process
A set of interrelated activities performed in a given order to process information or materials
The RE process
- shapes the information flaw
- communication model between participants
- defines the RE work products to be used or produced
- provides a framework in which RE elicit, document, validate and manage requirements
Overall process fit
- process might require wp that the RE process must deliver
- terminology in the RE should be aligned
Influencing factors
- overall process fit
- development context
- stakeholder availability and capability (exploitative, continuous)
- shared understanding (the more the more light weight)
- complexity and criticality
- constraints (customer or regulator)
- time and budget available
- validity of requirements (likely to change)
- experience of requirements engineer
Development context
- customer-supplier-user relationship
- development type
- contract
- trust
Development type
- a supplier specifies and develops a system for a specific customer
- an organization develops a system with the intention to sell it as a product or service to many customers in a certain market segment
- a supplier configures a system for a customer from a set of ready-made components
- a vendor enhances and evolves an existing product
Contract
- is there a contract or similar agreement that formal defines deliverables, costs, deadlines, responsibilities …
- fixed or iterative functionality …
Process facets
- custom-specific vs market oriented (development type)
- prescriptive vs exploratory (deals with purpose and role of requirements)
- linear vs iterative
Linear RE process
- requirements are specified up front in a single phase
- mostly heavyweight
- produce comprehensive requirements specification that requires no or only little adaptation or few changes during the design and implementation of the system
Criteria for choosing a linear RE process
- Dev process is plan driven and linear
- Stakeholders are available, know their requirements and can specify them up front
- a comprehensive requirements is required as a contractural basis for outsourcing or tendering the design and implementation of the system
- regulatory authorities require a comprehensive formally released requirements specification at an early stage of the development
An iterative RE process
- specified incrementally starting from initial goals
- interwine the specification of the requirements with the design and implementation of the system
- lightweight process
Criteria for choosing an iterative RE process
- Dev process is iterative and agile
- many requirements are not known up front but will emerge and evolve during the development of the system
- stakeholders are available such that short feedback loops can be established as a means of mitigating the risk of developing the wrong system
- the duration of development allows more than one iteration
- ability to change requirements easy is important
Prescriptive
- requirements constitute a contract: all requirements are binding and must be implemented.
- create a requirements specification that can be implemented with no or little interaction between stakeholder and developer
Explorative RE
- goals are not know a priory, concrete requirement have to be elicited => have to be explored
Criteria for choosing a prescriptive RE process
- customer requires a fixed contract for system development, often with fixed functionality, scope, price and deadline
- functionality and scope take precedence over cost and deadlines
- development of the specified system may be tender or outsourced
Criteria for choosing an explorative RE process
- Stakeholder initially have only a vague idea about their requirements
- Stakeholders are strongly involved and provide continuous feedback
- deadlines and cost take precedence over functionality and scope
- the customer is satisfied with a framework contract about goals, resources and the price to be paid for a given period of time or number of iterations
- It is not clear a priori which requirements shall actually be implemented and in which order they will be implemented
Customer specific RE process
- system is ordered by a customer and developer by a supplier for his customer
- supplier and customer might be part of same organisation
Market oriented RE process
the system is developed as a product or a service for a market, targeting specific user segments.
the organisation that develops the system also drives the RE process
Criteria for choosing a customer-specific RE process
- the system will be used mainly by the organisation that has ordered the system and pays for its development
- important stakeholders are mainly associated with the customer’s organisation
- the customer wants a requirements specification that can serve As a contract
Criteria for choosing a market oriented RE process
- the developing organization or one of its clients intends to sell the system as a product or service
- prospective users are not individually identifiable
- the RE have to design the requirements so that they match the envisaged needs of the targeted users
- Product owners, marketing people, digital designers, system architect are primary stakeholders.
Mutual influence of facets
- linear and prescriptive are frequently chosen together
- explorative & iterative
- market oriented does not combine well with prescriptive and linear
Agile setting best process
iterative and explorative
Prerequisite for using linear RE process
- sophisticated process for changing requirements is in place
- feedback loops are long - need intense validation
Three common facet combinations
- Participatory RE process: iterative & explorative & customer-specific
- Contractual RE process: linear & prescriptive & customer specific
- Product-oriented: iterative&explorative&market oriented
Five step procedure to configure an RE process
- Analyse influencing factors
- Asses facet criteria
- Configure
- Determine work products (aligned with the dev process)
- Select appropriate practices
Participatory RE process
- iterative & explorative & customer-specific
- supplier and customer collaborate closely, stakeholders are strongly involved in both the RE and dev process
- fits the agile process
- WPs: product backlog, user stories and task descriptions, vision, prototypes
Contractual RE process
- linear & prescriptive & customer specific
- development is tendered or outsourced to a provider with a contract based on comprehensive requirements specification
- requirements are a contractual basis for ppl not involved in the specification and with little stakeholder interaction after requirements phase
Product oriented RE process
- iterative & explorative & market oriented
- organization is developing a system as a product for the market