Section 2: Statement of Work (SOW) 3
2.2
Milestones and Deliverables4
2.2.1 Completion of Phase I: Analysis and Design 4
2.2.2 Completion of Phase II: Development/Code Construction 5
2.2.3 Completion of Phase III: Testing5
2.2.4 Completion
of Phase IV: Documentation 5
Attachment 1: Required Elements of Graphical
User Interface7
This document specifies requirements to implement an on-line recipe system. This introductory section provides information on the organization issuing this product, the target users, and the purpose of the product.
The Electronic Kitchen Helpers Corporation (EKHC) is issuing this requirements document. EKHC makes software products that help make the kitchen workers life easier. The target user for this product is average everyday cook or a commercial chef.
The purpose of the product is to store and retrieve recipes. The product must deliver satisfying user experience and provide maximum extensibility or sufficient framework for future visual and technical enhancements. Overall, the product is intended to achieve the following strategic objectives:
(a) Support EKHC customers/clients.
(b) Support the needs of the intended audience.
(c) Offer more interaction tools for the users.
(d) Increase the credibility of EKHC.
(e) Provide secure platforms that protect data and privacy.
The EKHC is seeking to expand its product offering and enhance customer service to its user community by making an on-line recipe system that is more accessible. Further, by expanding its product offering, EKHC will be better positioned to support future expansions in the electronic kitchen of the future.
The on-line recipe system needs to be browser based and have an open architecture allowing new functionalities that will also make information more accessible and facilitate process uniformity aimed at increasing user efficiency and productivity.
Initially, the on-line recipe system will run on a single user system running a Windows based operating system. The design should be such that the product can be expanded to operate under multiple operating systems as well as run in a distributed environment. The product will be completely usable in both Microsoft Internet Explorer and Netscape Communicator.
The developer will design, develop, and test the product according to the specifications listed in Section 2 of this requirements document. The browser part must use only those constructs that work with Microsoft Internet Explorer and Netscape Communicator. Widely available and free plug-ins and modified browser settings may also be used, with prior approval, as long as users are alerted about the actions they will need to do (e.g., download a software and/or adjust software settings).
The product development will consist of four phases or subtasks:
(a) Analysis of the requirements and design of the product
(b) Development//Code Construction
(c) Testing
(d) Documentation.
Following are detailed specifications of this requirements statement.
At the
conclusion of the project, EKHC will
have a well-designed Web-based product that uses industry standard
technology. The product will meet the
following specifications:
(a) Customer-centric design
(b) Consistent look and feel throughout the product
(c) Provides an immediate impression of personality, usability, and readability (i.e., users immediately know what to expect from the product)
(d) Attractive design.
(e) Shows clear product branding
(a) Uses dynamic content systems using database structures
(b) Meaningful and logical information flow or information architecture—clear information categories but with minimum content information layers; has the flexibility to accept and integrate new material (i.e., text, graphics, or Web applications) at any level or content category to keep content timely and appealing.
(c) Supports long-term accessibility (permanence of product structure)
(a) Quick and error-free search
(b) Intuitive functionality and ease of use so that users may easily locate information and browse information spontaneously.
(c) No left/right scrolling; reasonably short page length depending on page design and content
(d) Usable interaction design that gives the users a sense of control and freedom.
(e) Logical navigation scheme that allows access to the previous and next, or higher and lower levels of content categories. Has no orphan pages. Bears prominent navigation bars.
(f) Provides the complete scope of the recipe list.
(a) Import recipes from text-based file
(b) Input recipes from GUI
(c) Categorize recipes by foot type and nutrition information
(d) Search by recipe name or food type
(e) Print on 8˝ X 11 paper or 3X5 index card
(f) Output to screen via browser
(g) Capability to increase or decrease recipe size
(h) Output fractions as fractions, not decimals.
The on-line recipe system product shall perform the following subtasks:
2.1.2.1 Analysis and Design of the Product. In this phase, develop a written requirements document based on analysis and assess and recommend most critical requirements for the product. Recommend requirements in priority order. Develop a detailed content strategy, specifying the flow of information, navigational model, and also content life-cycles. In addition, define how the technical components of the product design will be built or set up. Produce a design document describing the product design.
2.1.2.2 Development/Code Construction. Develop all the required functionalities. In particular, produce product logos and other necessary graphical elements, and application GUIs and database interface. Develop the required databases.
2.1.2.3 Testing. Implement tests to determine the quality and reliability of the product and to refine the product’s visual design and technical components. Quality will be assessed through usability, accessibility, functionality, and details testing, where users, representative of the target audience, will test the product. Reliability of the product will be determined through tests of performance consistency and response time as well as load simulation tests.
2.1.2.4 Documentation. This phase will produce a user’s manual and
documented source code. The user’s
manual should be available in paper as well as on line.
Deliver one paper copy and one electronic copy using MS Word 97 or 2000 of each written deliverable.
Following are the milestones and their associated deliverables:
2.2.1.1 Requirements Analysis Document – A detailed document defining the requirements identified as part of Sub-Task 2.1.2.1.
2.2.1.2 Technical Specifications Document – A detailed description of the design and methodologies that will be employed in the development of the product.
2.2.1.3 Development Schedule and Plan – A detailed schedule, with weekly milestones, that should address the major components of the development process. This must include specific design/redesign steps, integration with other components, testing, and quality assurance.
2.2.2.1 Working System (all levels including database interface, search utility interface, and all identified technical components)
2.2.3.1 A detailed test plan. The test plan deliverable for this phase will include:
(a) Usability testing - which will gather input/feedback from test participants (the target users) on the look and feel, navigation, time and effort or usability issues that might present problems for the actual online users.
(b) Functionality testing - which will verify if the conform to specifications, and correctly perform all primary and required functions.
(c) Details testing - which will check the product's creative elements such as font types and sizes, graphics and layout, tables, frames, and forms. That is, if they are consistent with established design standards set forth in Phase I.
(d) Performance testing - which will include load testing ensuring non-error response, and performance tuning for faster response.
All visual design refinements and technical solutions implemented to address the problems identified in these tests must be listed in this phase's report deliverables.
2.2.4.1 Well documented source codes and pseudo codes for all product applications and logical and physical database designs
2.2.4.2 User’s manual
Present a weekly progress report to the Project Manager:
(a) Work accomplished during the reporting period
(b) Deliverable progress, as a percentage of completion
(c) Problem areas
(d) Planned activities for the next reporting period
(a) All milestone completion dates are met.
(b) All deliverables are complete and approved.
(c) All tests are completed successfully.
(d) All source code, object code, data files are complete.
(e) All documentation completed and updated as required.
Deliver completed products after every phase of the project as listed in Section 2.2 of this Task Order. Project Manager will determine satisfactory completion of deliverables.
All materials developed as a result of this Project shall be and remain wholly the property of the UNCP.
The following deliverables and dates will be met:
|
Deliverable |
Date |
|
Weekly Progress Report briefing charts |
Every Friday |
|
Requirements Analysis Peer Review Report |
August 30, 2002 |
|
August 30, 2002 |
|
|
Technical Specification Document Peer Review Report |
September 13, 2002 |
|
Technical Specification Document |
September 13, 2002 |
|
Development Schedule and Plan |
September 13, 2002 |
|
Test Plan Peer Review Report |
September 27, 2002 |
|
Test Plan |
September 27, 2002 |
|
Test Results Report |
December 2, 2002 |
|
Code Peer Review Report |
December 2, 2002 |
|
Working System Demonstration |
December 2, 2002 December 4, 2002 |
|
Source Code with Documentation |
December 6, 2002 |
|
User's Manual Peer Review Report |
December 6, 2002 |
|
User's Manual |
December 6, 2002 |