What & Why requirements? (approx 35 minutes)
“A requirement is….”something that the product must do or a quality that the product must have” (Robertson and Robertson, 1999)
Why Requirements?
As indicated in your text,(Preece, Rogers & Sharp, 2007) requirements issues have figured highly in IT project failure. Volere, a requirements resource site maintained by requirements engineering company The Atlantic Systems Guild inc. provides a tongue in cheek list of why you should consider NOT doing requirements.
Understanding your project
- Using the extract from the Volere template, make sense of your ePortfolio project brief by completing the first three sections. (There are three more sections included in case you want to think about these.)
-
Volere template provides more explanation.
What Requirements?
Requirements are defined in your text (Preece, Rogers & Sharp, 2007) as …”a statement about an intended product that specifies what it should do or how it should perform” They categorise requirements into:
- functional: which describe what the system should do, and
- non-functional: which outline what constraints there are on the system and its development
-
Review the resources from Volere and your text to understand the different kinds of requirements
-
Make sure you read the simple example provided in your text
- Complete the comparison table relating the Volere requirements to those outlined in your text
- Highlight those that you think are going to be relevant to your project brief.
How to establish requirements (approx 45 minutes)
Establishing requirements is an iterative process, much like other interaction design activities. You have already completed some of the preliminary work in finding out about your users in the previous topics.
Process
Like other finding out activities, the process involves: data gathering; data analysis, interpretation and presentation of results.
- Volere provide some useful advice on how to get started
- Skim this overview and work out what would be practical in the project you are embarking on
- Refer to the requirements document from Volere and see if there is any information that you could already include about your project (jot down some ideas particularly in the non-functional requirements section).
Data gathering techniques
Finding out activities of interviewing, observation and questioning form the core data gathering techniques for requirements.
-
Preece, Rogers and Sharp (2002, 2007) outline how to use these three techniques for the data gathering process and add two further techniques: studying documentation and researching similar produces and their use.
-
In contrast, Robertson (from Volere) identifies a range of activities for “requirements trawling” from simple brainstorming to those requiring specialist knowledge and expertise:eg neurolinguistic programming and soft systems methodology
- Review these resources
- As a group, decide what you need to clarify/find out about your project and which technique/s would be most helpful to do this
- Conduct your data gathering using other class members as prospective users.
Tools: analysis, interpretation & presentation (approx 45 minutes)
Requirements work must be documented for communication and use in design; the usual way of doing this is a requirements specification supported by illustrative materials. You have already begun the requirements specification using some of the materials from Volere. Now find out more about the illustrative materials.
Analysis interpretation presentation
Interpretation should begin as soon as some data has been collected.
-
Review the advice your text provides.
- Where appropriate, use the Volere shell to begin to document some of your non functional requirements.
Task descriptions
A range of devices can be used to describe the various tasks to represent the different system requirements including: scenarios, use cases, essential use cases.
- Your text provides an overview of these descriptive tools with lots of examples.
-
Review these in your text to become familiar with each technique, considering which will be useful to you.
- If you are working on an agile development approach, two resources are provided to illustrate how important use cases are to this environment.
-
The PowerPoint provided is an excellent overview of Use Cases highlighting the importance of communication in the process and providing some helpful examples.
- A template is also provided
-
Develop a scenario of the existing activity, users would do to achieve the goal the ePortfolio is seeking to replace.
- Develop a Use case (either traditional or agile style) to illustrate the most commonly performed set of actions by the user in your ePortfolio system. Represent your use case graphically (ensure that your use case relates to the requirements specifications you have been developing).
Task Analysis
Task analysis is a group of methods for investigating and representing an existing situation generally diagrammatically recording physical observable actions.
Preece, Rogers and Sharp explain two techniques for task analysis: Hierarchical Task Analysis (HTA) and Goals, Operations, Methods, and Selection rules (GOMS)
-
Review your text and the powerpoints provided to gain an overview of both processes
- Evaluate their usefulness to your current situation. Should this also be a technique you use?
Your ePortfolio (as long as you can afford)
So its time to develop a set of requirements for your ePortfolio. You will need some requirements specification supported by illustrative materials.
You can choose:
- to use the Volere template you have begun to develop supported by scenarios, and use cases you have developed in the proceding activities + any other important requirements that you think will need communicating within your team,
-
Use the requirements example as an overview of your requirements specification and supplement it with illustrative materials including scenarios, and use cases of the major functional requirements.
Post these on your website for communication with your client
