Statement of Work
Step 1 As a first step, you should discuss what (if any) business needs/requirements are either stated clearly, or inferred from the SMM proposal. Also discuss why you believe (or not) such needs/requirements should be elicited and stated for the SMM. Additionally state what issues you believe may arise concerning any lack of stated needs/requirements, and how you might deal with them in order to alleviate potential future risks.
Gurkan:
- The business requirements stated but not clear are:
- Request meetings, including the provision of -meeting deadline, topic, priority and meeting extent, who should attend, and suggested locations.
- Users of SMM can set preferences to be applied to meetings.
- Set conditions for meeting times.
- Set meeting reminder preferences.
- Associate documents with a meeting both before and after the meeting has occurred.
- Automatically inform SMM of potential absence from meeting appointment through knowledge of other meetings and activities. (To be implemented at a later release)
- Make appointments based on optimal and learned criteria about individuals and groups.
- Determine potential meeting times and locations based on users' preferences, availability, meeting deadline and extent, priority and other potential conditions or contexts.
- Inform users of appointment times via contextually determined connections appropriate for ensuring information is received. (To be implemented at a later release)
- Maintain a history of all meetings.
- Set and link regular meetings.
- Reschedule meeting when key invitees change their plans, or when a quorum is not possible.
- The SMM software is to be used in context with available communications technologies such as the internet, (mobile) telephone etc. to achieve meeting participation in "virtual" and "roaming" locations and be able to switch between physical and virtual, virtual and virtual, and virtual and roaming location contexts seamlessly.
- Use capabilities of current communications technologies to help identify meeting presence of any/all attendees.
CLIVE:
These are functional requirements not business requirements. You need to think company, not product here! What business requirement is SMM Pty Ltd attemtping to meet when they suggest creating a businees to build and sell SMM? Infact SMM Pty Ltd really only implies one or two basic businees requirements. They seem to be playing a game of dice and have very little (quantitive or qualitative) information to suggest whether there's even a business to be pursued.
Requirements defined by customer are not clear. Customer has a very good idea like SMM but real/clear requirements are not exist. Proposal paper looks like the result of a brain storming session. Also customer is not aware of the capabilities of a PDA or Hand Held computer. Our job is to make customer happy and deliver an acceptable SMM with the first release and let the customer make some profit from sales so the project (and our job) can continue. With this in mind we should define the deliverables for the first release to prevent the differences between customer's and ours understanding of requirements and deliverables.
When we are transferring the business requirements into Use Cases/Action Event List, there may be discrepancies between the actual customer requirements and translated customer requirements. To prevent this, customer or it’s representative should involve in the “requirements sign-off†process. With this approach, we will make sure that all the scenarios/use cases/action & events are the part of the big system and they are all required. This is one way of verifying the requirements from my experience. The only risk is that customer may inject additional requirements between the lines, but a good reconciliation process may filter them out.
CLIVE:
The customer has provided some basic requirements for a product that they are calling SMM. These requirements are based on what SMM Pty Ltd believe is appropriate to meet some unqualified demand for people within companies being able to organise meetings easier.
Step 2 Part of the process of eliciting SMM requirements has been to put questions to the customer (yours truly). This has been done in a rather ad hoc style with a large audience firing questions at the customer who, in turn, has had to react relatively quickly in order to avoid frustrating the contractor (you). Please discuss, from your standpoint as contractor, what you believe are the advantages and disadvantages of such an approach to elicitation.
Gurkan:
Firing questions to the customer is OK if it was in a well facilitated meeting style where a recorder and a meeting chairman was present. It is always good to be with the customer face to face during the requirements meetings. Meetings should not be longer than an hour and occur at least every week during the analysis phase. My very first day in a software development company was started by attending to a “requirements elicitation†meeting. I am thinking the customer like a kid; he has got lots of “things†to say but don’t know how to express those “thingsâ€. Our job is to help him/her to express those requirements in a way that both parties can understand and agree on them. During the ad hoc style meeting with customer in the class, I could not note most of the questions because when I was writing someone else was asking another question.
CLIVE:
Good answer.
Step 3 Another part of the process has been for you (or at least some of you) to put questions in writing and to receive written responses. Please discuss what you believe to be the advantages and disadvantages of this approach. In what ways is it different to verbally questioning the customer?
Gurkan
Questions will always arise at any point. If you write them and send it to customer, they can be interpreted differently and the answer could be totally different than your original question. If I have questions to ask to the customer, I usually degrade them to a "yes, no" or "true, false" or "multiple choice" type of questions so that there can't be a second meaning of the question. I keep my questions small at most 2 lines because long questions are hard to read and answer.
CLIVE:
You haven't really discussed the (dis)advantages.
Step 4 A forum has now been set up. Go to comp8100.talk on the forum list at http://cs.anu.edu.au/phorum/comp8100.talk. Please use this forum to ask further questions or to gain more incite into the requirements as questions are answered. Use it especially to help you progress with this assignment.
Gurkan:
I am using the forums. Thanks for this opportunity
Step 5 Identify and/or suggest three or four business rules that are likely to affect the sale and operation of SMM. Catalogue these rules as described by Karl Wiegers (see lecture notes and template).
Gurkan
Please go to BusinessRules document
Step 6 What constraints are obvious, and what (if anything) do you think is likely to become a constraint?
Gurkan
- Number of supported operating systems
- Number of supported hardwares
- Smart capability
- Intelligent meeting time adjustment
- Intelligent attendee recognition
CLIVE:
Budget and schedule are surely constraints. There are some technical constraints too - that you haven't mentioned.
Step 7 As presented on the comp8100 forum, the scope has been narrowed to include only the functionality relating to meeting management and some of the basic intelligence features that will help ensure reasonable outcomes for the setting and checking of meeting information. Requirements associated with natural user interfaces should be kept to the following core set:
- The requirements for switching between environments automatically through knowledge of location and activity are excluded from this first version of SMM. However, the first version should be designed and implemented in such a way that such features can easily be added in order to extend the overall capability of SMM.
- SMM should be portable to different environments and the appropriate interface functionality automatically determinable upon installation of the SMM software
Step 8 Develop three (3) non-trivial scenarios of use of the proposed SMM from the information that has so far been elicited from the customer. Depict each scenario in both Use Case and Event-Action List format. Discuss (from your viewpoint) the advantages and disadvantages of both formats after their completion. Which do you prefer?
Gurkan:
Use cases that I have created for the 3 different scenarios are:
- BookAMeeting
- DefineATimeForTheMeeting
- BookARoomForTheMeeting
The Event Action Lists are:
- EALBookAMeeting
- EALDefineATimeForTheMeeting
- EALBookARoomForTheMeeting
Both methods have strengths and weaknesses. I prefer a mixture of both. I would first create Event Action List and detail each event as a Use Case to identify actors, flows, level of use case, actions and alternative actions. This also depends on the size of the project and time constraints. Writing detailed use cases will consume more time than writing event action lists. Also if I am using a UML case tool, I would prefer use cases to see the flow between the use cases and to branch down to detailed design so that each software module/component could be traced back to use cases and requirements.
CLIVE:
See my comments in the U/Cs.
Step 9 Write a partial VSD and equivalent OCD on the basis of all the previous collected information remembering that the OCD will need to be tailored. Limit your descriptions to the features/requirements and constraints that you can identify from the use cases and/or event-action lists that you've constructed. Discuss the advantages and disadvantages of both the VSD and OCD.
Which do you think is more amenable to the SMM problem?
Gurkan:
VSD and OCD are similar documents that you need to create at the beginning of the project to identify the scope, limitations, resources and possible extensibility features. You can use more imagination with VSD but OCD is specifically addressing the customer requirements and not mentioning the future enhancements. My selection between the OCD and VSD depends on the customer. If customer is flexible and prioritise the features and divide them into releases then VSD is a good option. If customer is strict about what he/she wants and if the product is one-off product where there is no subsequent releases then I would use OCD. Please use below links to browse to VSD and OCD documents for SMM.
I think VSD is more amenable to the SMM project, it allows inclusion of future release features.
CLIVE:
Good answer.