This is an individual assignment.

1. MonoSoft Corporation wants to get into the meeting scheduling and time management market with a product code-named Drudgery99. Drudgery will manage individual schedules of individuals at work and will make their schedules available (with suitable privacy levels and security from outside prying) to their co-workers. Drudgery will automate some of the drudgery that co-workers encounter when arranging to meet. MonoSoft has big plans for Drudgery and would like to see half the companies in North America using Drudgery within five years.

(a) Who are MonoSoft’s customers? Describe the steps that it should take to identify and validate customer requirements adequately.

5 marks: Customers (i.e. beneficiaries) are employees (office workers) in the purchasing organizations whose time is to be scheduled. Discuss with marketing dept. or client organization representatives who in addition to them will decide on adequacy of system. (prob. sample end users, facilities managers or others responsible for space and equipment, administrative assistants and secretaries.)

10 marks: Domain analysis through interview and observation to understand how meeting scheduling is typically done and what problems occur. Walk through scenarios, possibly with UI storyboards or prototypes. Document requirements informally for customer approval and more thoroughly in functional specification. Review/inspect spec. within project for completeness, consistency, feasibility, etc.

(b) A document available on the web is a draft requirements definition for Drudgery99. Imagine that you are preparing for an inspection of this document with several other reviewers from the marketing and product engineering departments. For the purpose of this inspection, you should restrict your attention to the description of the initial version of the system and ignore the final section (12) of the document that deals with its future evolution.

(I) Write a short paragraph evaluating the chances of success of the Drudgery project if this document is used as its requirements definition;

5 marks: Not very good. It's too vague and does not say what will be automated or what assumptions are being made about scheduling and communication mechanisms available in the environment (e.g. email addresses etc.)

(II) Mark up a printed copy of the document with at least five issues of clarification [i.e. "what is meant by...?"] that you want to raise in the inspection meeting;

20 marks: See example marked-up version.

(III) Mark up the printed copy with a further five issues of the form "what would happen if..."

20 marks: See example marked-up version.

2. Like it or not, the requirements definition document is approved, and all the issues that you raised were agreed to be "interesting, but will be addressed in Version 2," and the requirements document (excepting the final section on future evolution) is now the definitive statement of the requirements for Drudgery99. The architectural design team comes up with an architecture for Drudgery99 that should be familiar to you by now.

(a) The initial test plan for the system, which is to be released in May 1999, has the modules in the architecture being reviewed, implemented and unit-tested in isolation before or during March, 1999. Integration of the modules into the release will take place during April 1999. Evaluate this proposal.

10 marks: Terrible. For a system with this complexity, one month is insufficient for integration and integration testing. Big-bang integration of the units will inevitably lead to a spate of difficult-to-debug defects being discovered less than one month before release. The release date will have to be slipped (or a known defective product released according to schedule).

(b) As a reward for making such a fuss, you have been appointed senior quality assurance engineer for the Drudgery99 project and are given a week to come up with a build- and integration-test plan for the product. Document your plan as a table in the following form, and explain your integration strategy:

(I) You do not have to put any dates on the plan; a time-ordered sequence of builds is sufficient.

(II) You may assume that modules will be implemented and unit-tested in any order that is convenient for your plan and that there are no resource shortages to consider.

(III) You may want to break a design module into sub-modules for the purpose of thread testing, but you do not have to. If so, attach a note of explanation and go ahead and assume that the Drudgery architecture really is structured into the modules that you would like. (E.g. You could decide that "ChooseBestTime" should really consist of "ChooseBestPlace" and "ChooseBestTime", which you want to integrate at different times.)