根据要求，代写软件需求说明书的第一部分。
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:
- Your name and student ID and the name and student ID of your partner.
- A vision statement for the project on which you are the engineer one paragraph.
- A short Software Requirements Specification SRS using the SRS template ~10 pages.
- A Use Case Diagram 1 page.
- A Use Case Description for the three most important use cases ~3 pages.
- A Sequence Interaction Diagram for the most important use case 1 page.
- Prioritisation explanation: How did you decide which use cases are the most important” one paragraph.
- 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.
- 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.
- 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.
- 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
- 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.
