Chapter 4 - Part II Flashcards
Requirements Engineering
Generic activities common to all processes
▪ Requirements elicitation;
▪ Requirements analysis;
▪ Requirements validation;
▪ Requirements management.
In practice, RE is an iterative activity in which these processes are interleaved.
Problems of requirements analysis
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organizational and political factors may influence the system requirements.
The requirements change during the analysis process.
Requirements elicitation and analysis / Stages / People Involved
Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.
May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
Stages include:
▪ Requirements discovery (interacting with stakeholders to discover requirements)
▪ Requirements classification and organization (organizing/classifying requirements into groups)
▪ Requirements prioritization and negotiation (prioritizing requirements, resolving conflicts)
▪ Requirements specification (requirements are documented)
People Involved:
1) list the stakeholders involved that impact the development of the product.
2) End-Users, those who are going to use use the product.
3) Top Management might pay for the product, but they don’t necessary use the product.
Interviews / Effective interviewing
Best approach might be combining different methods (open ended + closed)
Interviews: data collection method, where we can ask questions and the other party will answer them.
Types of interviews
▪ Closed interviews: based on pre-determined list of questions (you control the discussion, not the stakeholder)
▪ Open interviews: where we ask a question and allow the stakeholder to talk, be creative (not focus on specifics)
Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.
Interviews are not good for understanding domain requirements
Effective interviewing
▪ Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders.
Scenarios
Scenarios are real-life examples of how a system can be used.
They should include
▪ A description of the starting situation;
▪ A description of the normal flow of events;
▪ A description of what can go wrong;
▪ Information about other concurrent activities;
▪ A description of the state when the scenario finishes.
Use cases
Use-cases are a scenario based technique in the UML (Unified Modeling Language)
which identify the actors in an interaction and describe the interaction itself.
A set of use cases should describe all possible interactions with the system.
Ethnography / Focused ethnography
Part of observation techniques (observing/analyzing how people actually work)
Ethnography is effective for understanding existing processes but cannot identify new features that should be added to a system.
Focused ethnography:
- Combines ethnography with prototyping
- Prototype development results in unanswered questions which focus the ethnographic analysis.
- The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant.
Ethnography & Prototyping
(The process of implementing a focused ethnography)
1) Identify a specific situation
2) You try to understand how things are done in this situation.
3) You develop a prototype to implement for that situation.
4) You actually execute the experiment.
5) You take notes.
Requirements validation
Validation involves asking the client “Is this what you want?”
Important, because if we make any errors, that will impact the whole project management process.
Requirements checking
Validity. Does the system provide the functions which best support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer included?
Realism. Can the requirements be implemented given available budget and technology?
Verifiability. Can the requirements be checked?
Requirements validation techniques
Requirements reviews
▪ Systematic manual analysis of the requirements.
Prototyping
▪ Using an executable model of the system to check requirements.
Test-case generation
▪ Developing tests to check testability.
Review checks
Verifiability
▪ Is the requirement realistically testable?
Comprehensibility
▪ Is the requirement properly understood?
Traceability
▪ Is the origin of the requirement clearly stated?
Adaptability
▪ Can the requirement be changed without a large impact on other requirements?
Requirements management / Planning / Process
the process of managing changing requirements during RE Process & system development.
Planning:
1) Requirements Identification
2) A change management process
3) Traceability process
4) Tool support
Process:
Deciding if a requirements change should be accepted
▪ Problem analysis and change specification (the change proposal is analyzed to check that it is valid)
▪ Change analysis and costing (a decision is made on whether or not to proceed with the requirements change)
▪ Change implementation
(the requirements document and, where necessary, are modified)