Assignment 1: Requirements elicitation and specification: Overview
You have been made responsible for developing the Requirements for a major software project. You have access to a client representative and any publicly available information that might help you.
In the first iteration of requirements development (which is all that you need to do for this assignment) you will gather whatever information you can, develop a detailed draft requirements document, and develop a detailed plan for how you would do further requirements development in future iterations.
Unfortunately, I can't really let you loose on 150 client representatives, so instead we are going to simulate the client representative using one another.
Teams of Two
You will need to pair up with another student to form a team of two. As agreed in lectures, we have waited until after the census date, and correspondingly delayed the assignment submission date, to ensure that the people you pair up with are continuing students of comp255.
You can start now to find a partner for your team.
Every student needs one and only one partner who must be another student of comp255. Find yours now!
There are an even number of students in comp255. (Why is that important?) You should work hard to find a partner right away, but if everyone you talk to is already part of a team, then after the lecture on Wednesday we will get the people who are having trouble finding a partner to meet one another.
Be sure to have a partner by Thursday at the latest. And even if you haven't found your partner yet, you should start planning immediately. Read on...
How teams will work
The assignment is an individual assignment. Each student will submit their own results from their own requirements elicitation (as described below). But in doing your requirements elicitation you will frequently need to speak with your client representative. That person is the other person on your team.
So, you will simultaneously be working as a consultant developing the requirements for one project, and as a client representative answering questions and providing information to the consultant (the other member of your team) developing requirements for another project.
And yes, there are two projects, Project A and Project B. On one of the projects you will be acting as a software engineer, on the other you will be acting as a non-IT person. You must work hard to fulfil your role. It will require creativity, careful thought, and indeed -acting- in the sense of being able to pretend to be someone you are not, and to properly think and talk -in role-.
I will leave it up to the members of each team to decide who is the software engineer on which project. You cannot both work on the same project. Agreeing on who works as the engineer on which project might require some negotiation. Teamwork always involves careful negotiation with one another.
What you must submit
You will be required to submit one document which should not exceed thirty A4 pages and must contain the following:
1. Your name and student ID, and the name and student ID of your partner.
2. A vision statement for the project on which you are the engineer (one paragraph).
3. A short Software Requirements Specification (SRS) using the SRS template (~10 pages).
4. A Use Case Diagram (1 page).
5. A Use Case Description for the three most important use cases (~3 pages).
6. A Sequence (Interaction) Diagram for the most important use case (1 page).
7. Prioritisation explanation: How did you decide which use cases are the most important? (one paragraph).
8. A report to your boss explaining what techniques you used to elicit the requirements you've reported (1-2 pages). This is very important. Be sure to include a fair amount of detail.
9. A report to your boss describing how useful you found the client representative to be, what working with him or her was like, and some of the best and worst things that person did in their role (1 page).
10. A plan for how you would, if you were continuing the project, further develop the requirements. What other information do you need, and how do you think you could get it? What would you do to be sure that you have the -right- requirements? (~2 pages).
11. A report to Mike describing how well you thought you played your part as a client representative for the other project. What did you do that you are proud of? What was difficult? (1 page)
Be extremely well-organised, and make sure your submitted work looks like a professional document.
Remarks on some of the artifacts:
Use Case Diagram: This is a graphic model showing the actors, the use cases and the relationships between them. One page should be sufficient. As a rule of thumb – if the description of a use case is very short (e.g. one or two steps only) or very similar to another use case, then consider combining the use cases and describing the alternate courses of action within that use case. Structure the use cases into logical groupings. Remember that they are from the users’ points of view – not the developers' points of view.
Use Case Description: For each use case, there needs to be a corresponding textual description. Please use the template (see the Resources Section). Sub-use cases may be combined into one use case description. For example, if you had a use case Maintain User with sub-use cases Adding User, Deleting User, Viewing User or Modifying User, you could just write one use case description for Maintain User and describe the differences by branches in the use case steps.
Sequence Diagram: One sequence diagram for one use case description. It should be possible to read the description and follow what is happening on the sequence diagram. Think carefully about the participants. They will include the relevant actors of course, but there will also be objects that will be part of your system, and the interactions between the actors and the main objects need to be shown.
Domain Model: I would have asked you for a domain model, but I have tried to keep this assignment to a minimal deliverable (and already, as with many Software Engineering documents, it's quite long). You may nevertheless find it helpful to develop a domain model. If you do, keep it. It may be useful in assignment 2...
Remarks on being a client representative
Please remember that client representatives are not usually IT people. When you are playing a client representative it is not your role to try to help the software engineer with any engineering or IT issues. Instead, you are a source of information about the business. But of course you don't know everything about the business. Try to imagine yourself in a particular role in the business, and so conclude how you should act, what you should know, how you can answer questions, and so on. Aim to be as realistic as possible. But be creative too -- you have an important role to play, and it is a fictitious role, so you have many choices about how it will play out. You get to make up things about the business and about what it wants. Do your best to be realistic, and if you can make it interesting (sensibly!) all the better.
For this exercise, do always be civil and cooperative. As a representative of the client, you want the project to succeed.
Other documents to help you
Separately from this document, there are pages which describe the two projects. Look for them. They are near by.
Also check the Resources Section. There are templates and other documents there to help you.
And of course, you can, and should, read more broadly to develop your ideas both about good software engineering practice, and about the areas of your specific projects.
Need further help or clarification?
First, read all of what is here very carefully. The specification above tells you a great deal, but needs to be read and interpreted carefully (in common with all technical documents).
If you still feel a need to ask about anything, do please do so. Talk to Mike after any comp255 lecture. He always likes to talk to you (but do be sure that you've thought hard about whatever you're asking about before talking to him).
And finally...
Enjoy the challenge this assignment presents. There is a fair bit of work in getting a coherent set of documents together to make your submission, but it is an important, and interesting, experience.
And enjoy working with one another. A cooperative team of two can be quite creative and can have an interesting time doing this. Do be serious about your work, but have fun doing it.
Assignment 1: Project B
You have been approached by a client who has an idea for a system that they intend to offer to sell to Cochlear.
The problem as they see it
Many hearing impaired people benefit significantly from aids of various kinds (ranging from simple hearing aids to cochlear implants). These devices assist in hearing and, with training, interpreting sounds. But some people who have benefited from these devices have significant difficulty in localising sounds. They can hear, and interpret, a sound, but they don't know what direction it came from.
This can cause particular difficulties in, for example, a room with many people talking. People with normal hearing can focus their attention on the sounds coming from a particular direction and effectively filter out many of the other sounds (called extraneous signals). But people with well-functioning aids hear sounds from all directions clearly, including extraneous signals, resulting in confusion or fatigue from the effort of trying to extract the relevant signal (for example, the conversation that they are trying to follow) without good positional cues.
The idea
The client has experience in the electronic music industry. They have been very successful building systems that allow precise timing of -reverb-. Their systems detect sounds and generate a small and precisely controlled delay before repeating them. This is like an echo. The delay can be varied or multiple delays can be used at once providing varying experiences from a traditional echo (a delayed repeat as one might hear in shouting across a large valley), through the kinds of echos that sometimes happen in telecommunications (have you ever talked on the phone and heard your own voice repeating what you've said just a little after you've said it? It can be very disconcerting...), or with carefully chosen delays their systems can generate rich reverberant sounds such as one hears in a cathedral or a particularly aurally -warm- concert venue.
The client is aware that much of our ability to localise sounds comes from the short delay between a sound arriving at one ear, and at the other ear. When there is no delay the sounds is directly ahead of, or behind, us -- the sound arrives at both ears at exactly the same time. Longer delays arise as the sound is moved more towards our sides, with the longest delays when the sound comes directly from our right or left.
The client believes that they could, with the right software, miniaturise their technology sufficiently to include it in hearing aids of various kinds. The hearing aids would have detectors on each side of a person's head. The software and the client's hardware would take those sounds and exaggerate the time differences to make it easier for the wearer to focus on a particular time difference (ie on sounds coming from a particular direction) and exclude from their attention those sounds with longer or shorter time differences.
They are also interested in the differential effect of the pinna on incoming sounds, and as an extension of your work they might be interested in software that could mimic those effects if they too helped with sound localisation.
Your responsibility
The client has sent a representative to you to ask you to plan the software requirements for the new system.
Structure for your SRS document
The SRS format I would like you to follow is close to the IEEE 830-1998 IEEE Recommended Practice for Software Requirements Specifications.
A description of what is in each of the headings is provided in the IEEE document linked in the resources section of the COMP255 iLearn page.
You may use any document template or style that you like, but you must include the following information in your document...
SRS Structure
For your SRS, please include the following headings in your SRS:
________________________________________
Title Page
• include details of project name, product or products by name
• student names and student numbers
Revision History
• Table of dates with:
o what has been changed from each version of the SRS and
o who made the changes and
o who verified the change
Introduction
(This section introduces the project, the document, and the systems being described)
• Purpose
o (Of the document, the intended readership of the document, description of the document conventions being followed)
• Scope
o (Of the whole project and your development)
o ... perhaps consider using a context diagram to describe the scope of the system.
• Definitions, acronyms and abbreviations
• References (any sources, documents or other dependent material used in developing this document)
Overview
• Overall description
• Product perspective
• Product functions
• User characteristics
• Constraints
• Assumptions and dependencies
Specific requirements
• Use any breakdown method you wish (e.g. by user, role, function, system mode, ...)
• Make sure each requirement is uniquely numbered and identifiable
• Be sure that for each requirement you include “Fit criteria” which detail what measures any tests of the system need to pass to be deemed to meet the requirement.
Appendices
(not included in your page count)
• At the end of your SRS you should append your other deliverables including the use case diagram, use case descriptions, sequence diagram, reports, etc.