Aims of this chapter
- Describe different kinds of requirements
- Enable you to identify examples of different kinds of requirements from a simple description
- Explain how different data gathering techniques may be used during the requirements activity
- Enable you to develop a scenario, a use case, and an essential use case from a simple description
- Enable you to perform hierarchical task analysis on a simple description
Summary
What, How and Why
The process works in a cycle..
Why bother? The importance of getting it right…
- A large number of IT projects fail due to bad implementations or incorrect specifications.
- It is cheaper to analyse than to develop
- If you identify the needs initially substantial savings in costs
What are requirements?
Two types of requirements typically identified
- Functional Requirements – the core problem it aims to solve. What a product should do.
- Non-functional requirements – size, speed…
Other types of requirements include…
- Data requirements
- Environmental requirements
- User characteristics
- Usability goals and user experience goals
Data gathering for requirements
The main purpose of data gathering for requirements is to collect sufficient relevant, and appropriate data so that a set of stable requirements can be produced./
3 common forms of data gathering include
- Interviews
- Questionnaires
- Observation
Interviews include…
- Structured Interviews
- Semi Structured Interviews
- Unstructured Interviews
- Focus Groups
Observation include…
- Direct observation
- Indirect Observation
- Studying documentation
- Researching similar products
Contextual Inquiry
Contextual inquiry is one of seven parts of contextual design, which is a structured approach to the collection and interpretation of data from fieldwork with the intention of building a software-based product.
Contextual inquiry rests on four main principles
- Context – go to the workplace and see what is happening
- Partnership – developer and user should collaborate in understanding the work
- Interpretation – observations must be interpreted in order to be used in design
- Focus – Keep the data gathering focussed on your goals
Data gathering guidelines for requirements
- Focus on identifying stakeholders needs
- Involve all the stakeholder groups
- Support the data gathering sessions with suitable props
Data analysis, interpretation, and presentation
The aim here is to structure and record descriptions of requirements.
Various methods to diagram these at different levels including class diagrams, sequence diagrams, Entity Relationship Diagrams
Task Description
Descriptions of business tasks have been used within software development for many years. There are many different flavours of task descriptions including the following…
- Scenarios – informal narrative description that allows exploration and discussion of contexts, needs, and requirements emphasizing the context
- Use cases – focus on user goals, but emphasis is on a user-system interaction. A use case has one or more actors, goals and normal course (outcome desirable). Generally described graphically
- Essential Use Cases – represent abstractions from scenarios and tries to avoid the assumptions of a traditional use case
An essential use case is a structured narrative consisting of three parts:
- Name that expresses the overall intention
- A stepped description of user actions
- A stepped description of system responsibility
Task Analysis
Main purpose is to investigate an existing situation, not to envision new products. Used to analyse the underlying rationale and purpose of what people are doing and what they are trying to achieve.
Hierarchical Task Analysis
Involves breaking a task down into subtasks and then into sub-subtasks. The starting point is the user goal, this is then examined and the main tasks associated with achieving that goal are identified. Where appropriate these tasks are subdivided into subtasks.