Other代写:COMP255 Requirements Elicitation and Specification Part1

根据要求,代写软件需求说明书的第一部分。

Requirement

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.

You should already have a partner for your team.

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 you really should have found them last week. 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. 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 “sign-off” from the client representative stating that they have received copies of your submission versions of items 1-6 above. The client representative does not need to be completely satisfied with your work on those items this is still early in the Requirements development but they must receive and keep a copy of 1-6 in the form that you wish to have marked and they need to receive it on or before the assignment due date. The copy that your client representative has may need to be reviewed during the marking process. In your role as a client representative keep your copy of your partner’s work safe.

Be extremely well-organised and make sure your submitted work looks like a professional document.

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. Subuse 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 after 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 will be pages which describe the two projects. Look for them. They will be 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. And we will be talking about many of the artefacts in lectures over the next couple of weeks.

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.