Reference no: EM132400417
Assignment : 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.
Every student needs one and only one partner who must be another student of comp255.
There are an even number of students in comp255. (Why is that important?) If you don't have a partner then 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 (details nearby soon). 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)
12. A log of your interactions with your partner including date, time, duration, topic, and main decisions from that interaction. Each entry can be brief, but logs are important and should be kept accurately and up-to-date. Make an entry every time you interact. Start your log today (or if you really can't contact your partner today, be sure to start tomorrow!).
Today you can decide who will be the software engineer for which project (A or B) (it's often best to do that, at least as a default position, before you see the projects -- you can always swap if you both agree, but deciding now before you see the projects helps avoid arguments if you later find you both would prefer to do the same project). Note that you maintain and submit your own log, independently of your partner's log, and this is an honest log (like the "report to Mike" above), it's not something that you do in-character. Just keep a clear and honest record.
Be extremely well-organised, and make sure your submitted work looks like a professional document.
You have been approached by a client who has an idea for a system that they intend to offer to sell to Transport for NSW. The problem as they see it
A recent media article has identified particular dangers that arise from the unsupervised operation of train doors on the new Sydney Metro.
The North West Rail Link (Metro) was designed to operate fully automatically, with no humans staffing the trains. The requirements for the system were originally developed for an Asian railway which operates very effectively, and on a light inspection it seemed that those requirements could be used for a system here with little change. However it is now clear that Australian passengers expect quite different behaviour from their train doors...
In particular, the Metro has an announcement to "please stand clear of the closing doors", and passengers are expected to stop boarding or alighting from the train, and to stand back and watch the doors close. However, the Metro is integrated into the Sydney Trains system, which has an announcement "doors closing, please stand clear" which is used frequently by human conductors in busy times to hurry passengers onto the train, so the announcement is sometimes heard two or three times, often with breaks between them, and the doors are only closed when the human conductor has ascertained that all intending passengers have boarded the train.
Unsurprisingly (at least to those who study human behaviour), passengers do not distinguish between the two announcements, and many passengers continue to attempt to board the Metro trains after the announcement and this is potentially quite dangerous if the doors close while they are doing so. And it is presumably this learned behaviour which led to the distressing separation of mother and toddler described in the media article linked above.
The current workaround
After the very negative media attention, Macquarie University Station staff have implemented a workaround.
During busy times when crowds of passengers are likely to try to continue to board the train, a staff member may use the maintenance override switch located atop one of the pillars, to lock the doors open and supervise the passengers boarding, only releasing the switch once everyone has boarded. In addition, they have even allocated extra staff to block access to the train from escalators when the doors are closing to avoid having a flow of arriving passengers attempting to board the train.
The maintenance override switch is only intended to be used when the train services are suspended and the stations closed to permit track work, and it opens the platform based barriers. The trains themselves have an interlock that ensures that if the platform barriers are open then the train doors can't be closed, and so the train is held in the station.
Of course, all this has several disadvantages including a commitment of unbudgeted staff to extra roles, concerns that staff have not been properly trained for a conductor role but are effectively being asked to carry one out, and the risk of the revealing of the maintenance override switch to the public and its possible misuse at times when the station and trains are operating but totally unstaffed (late at night for example).
The idea
The client has expertise in building access and security systems. These include infrared, ordinary light, and physical (touch based) detector systems that can be used to identify and track people in building foyers or passing through building entrance barriers. The client believes that they have substantial experience that could be relevant to the problem.
Their currently rather vague idea is to offer to retrofit stations with some of their detectors to track passenger movements, and to link the software that monitors those detectors to the maintenance override switch software, to provide a safe and fully automated (unlike now) door closing service along the Sydney Metro.
The client is also aware of similar potential problems with the new and as yet inoperative light rail service to the Eastern Suburbs, and with plans for Sydney Metro West which is yet to be built and could incorporate the client's technology into the planning for those services if it has proved successful on the current Sydney Metro. So they are eager for a successful system to be developed quickly.
As an extension of your work the client may be interested in your view of how any proposed system could also be extended to maintain counts of boarding and alighting passengers so as to automatically estimate the current passenger load on the train. (Other services on the Sydney Trains network do routinely provide load information which is displayed on real-time apps and on platform based destination boards, but the load is determined by on-train staff observation, and again, there are not meant to be staff on the Metro services.)
Your responsibility
The client has sent a representative to you to ask you to plan the software requirements for the new system.
Remarks on some of the artefacts:
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 later...