ITEC-630 Fall 2009
Prof. J. Alberto Espinosa
Last
updated 8/19/09
To be done in small teams of 3-4 members
[Scenario] [Delivery] [Grading] [Application] [Deliverables] [1] [2] [3] [4] [5] [6] [Final]
This assignment is intended to give you a valuable hands-on experience with a skill that you may actually use in practice. The exercise is not perfect, but neither is any requirements gathering project in real life. Your instructor will greatly appreciate any feedback and comments you may have at any point during this project. Your team will work on a consulting assignment to: (1) gather business requirements for a system implementation; (2) prepare the respective formal requirements and design specification document for this client; and (3) develop the corresponding database design.
Specification Template
Your requirements and design specification MUST be be prepared following a Requirements and Deisgn Specification Teamplate adapted by the instructor for your projects. You are not strictly required to follow this template, but you should consult with your instructor if you want to use a different template. This adapted template contains the specific sections that your instructor expects to find in your Final Project document, along with all the requirements forms that you may need, along with basic instructions and diagram examples.
This template is a reduced and adapted version of the Volere Requirements Specifications Template, which is one of several popular templates used for requirements specifications.
IMPORTANT: You will notice in the template that most large diagrams and artifacts
(use cases, etc.) go in appendices. This format is very useful for your clients
because they can quickly detach all diagrams for discussion in meetings.
Furthermore, moving all diagrams and figures to appendices will make your
text descriptions flow better. Please
follow this advice: every figure included
anywhere in the document needs a brief reference and explanation in the text;
and every appendix include in the document needs a reference and brief summary
of the appendix contents in the main text. Orphan diagrams and appendices
without reference or explanations in the main text are a very BAD idea and
consultants will complain about this.
Use Cases
A
central piece of your requirements specification will be the "use
cases" you will prepare for your application. Use
cases contain text in special forms that describe important aspects
of the systems' funcional requirements and part of the "unified
modeling language" or UML which
is the most widely adopted standard to describe systems. Your requirements
specification should contain 10 to 12 use cases.
Database Design
Your database design should include 10 to 12 database tables, an "entity-relationship diagram" or ERD, a relational design and implementation in MS Access, and sample queries.
Important Files to Maintain and Submit
Throughout the project, you will need to maintain at least 3 files (it is important that you use these EXACT file names when you submit deliverables on your web sites -- more on this later). Only one student in each team is required to post these files (but students can rotate who hosts the files any time):
Project.doc: this file will start with the empty template described above and you will complete, refine and submit the corresponding sections according to the deliverable schedule posted on the Class Schedule web page. This document will contain all your requirements specifications, diagrams, artifacts and other narratives.
Project.vsd: this file will contain your MS Visio data model. This file is not really a requirement for the course (you will copy and paste your diagrams to Project.doc) but you will be using MS Visio to create your data model and this source file is very useful when you need help from your instructor.
All deliverables will be made electronically, as explained here. All deliverables and final project should be delivered in a SINGLE Microsoft Word file called Project.doc (exactly, no blank spaces), a SINGLE database file called Project.mdb and a single MS Visio file called Project.vsd. Each team needs to have a Web Master, selected at the beginning of the semester. These files will be delivered by uploading this document into the Web Master's WWW folder in his/her G drive. Ideally, all team members should have their own copy of this document in their own WWW folders (as a backup and for individual reference). Therefore, if anything goes wrong with the Web Master's site (it happens), team members can send me an e-mail to let me know where to find it.
Each deliverable and the final project
are due at the beginning of class when due, per the Class Schedule
(we may open these files and discuss them in class). Late deliveries,
and incomplete or inadequate deliverables will carry a substantial penalty towards
20% of your team's final project grade.
[Top] [Schedule]
(10 pts) Clear description of requirements, good writing style, no grammatical errors/typos.
(10 pts) Content quality of the Project.doc document and consistency across documents
(20 pts) Adequate and timely progress on deliverables
(20 pts) Content quality of the functional requirments
Vision, funtional requirements, including use cases, context diagram,
use case diagram, actor specificatios cards, requirements shell cards,
non-functional requirements
(20 pts) Content quality of the final database implementation
CRUD matrix well developed, ERD well formulated,
Tables properly implemented (attributes, primary keys, etc.),
Relational design well implemented (foreign keys, update/delete/business rules, etc.),
Lookup pick lists properly implemented, data properly entered,
SQL queries properly implemented, etc.
(20 pts) Good relationship and communication with client and effective final presentation
The Business Application for the Project
Your instructor will share with you a number of business applications concepts he has discussed with various clients. You will need to form teams early in the semester. Your instructor will assign a project to your team trying to follow your preferences as much as possible. Teams can also propose their own project concepts if they wish, but all projects must have external clients who are not members of the student team.
As with most system development assignments, there are project deadlines and deliverables. The process you use to carry out this project is as important as the final delivery of the project. In fact, research has found that bad system development processes lead to bad project implementations.
Your final project
will be graded upon completion at the end of the semester.
However, the requirements and database development processes you will use in
this project will be completed in progressive iterations. You
will need to submit deliverables that show your progress on
the project. The
instructor will evaluate your progress and how well you are complying with
the deliverables outlined below. Timely
and adequate completion of deliverables accounts for 20% of your team's project
grade. IMPORTANT: teams some times fall behind for good
reasons. Your instructor will provide you with reasonable flexibility on deadlines,
provided that you discuss your reasons and needs BEFORE the deadlines (like you
would with your clients in any real project). The
timeline for the following deliverables is outlined in the Class
Schedule. The specific deliverables are:
[Top]
[Schedule]
Project Deliverable 1: Inception & The System Concept
Download the Project Requirements Template (here or from the class schedule) and save 2 copies. Name the first file project.doc and the second one ProjectTemplate.doc. Keep the Project Template file as a reference for your project, which contain all the necessary instructions for each section.
Open the project.doc file and remove all the instructions (embedded in brackets). This file should be totally cleaned up so that you can use it for your project requirements specification. This is the file you will be showing your clients from time to time, so please ensure that it is formatted properly, it is free of typos and grammatical errors and it has a businesslike and attractive appearance.
From this point forward, you are required to prepare and submit all your deliverables in this project.doc document. Each week, as you prepare your deliverables, you will be adding new information and updating/refining the existing information.
Using the appropriate sections of the project.doc file provide a brief and concise, yet informational system concept description for the project you have selected for the course. This concept should be about 1 page in lenght - single spaced - and should contain at least the following information:
The client you are working with selected
The business application for your project
A high level description of what the business processes and functions that the application needs to handle
A list of each stakeholder of this
system along with a brief description of their role and stake in the
system. This description should not contain names, but roles (in case
the people involve change). This description should mention whether the
stakeholder has a vested interest in the system or will somehow be affected
by the system implementation.
Note: In a real project, the stakeholders
are all the people you would want to interview to get the full picture
and multiple perspectives of the system that will be developed.
[Top] [Schedule]
Project Deliverable 2: More Inception, System Scope and Context
In each deliverable, you will start the required artifacts (e.g., diagrams, documents), but these artifacts don't need to be in final form. It is common practice in iterative system development methods to start something in one iteartion and refine/elaborate later. It is important to start with a general high level view of your artifacts and add the necessary detail later. This will save you a lot of re-work time. You will refine your previously submitted work in each deliverable.
Review and refine all your work submitted in the prior deliverable.
Important: this is probably the most involved deliverable and it may seem a bit overwhelming. However, please note that this deliverable is meant to help you develop a good high level view of the application. A common mistake is to over do this deliverable with too much detail, which will inevitably lead to future rework and corrections. Notice in all the descriptions below that you don't need to identify all processes, actors and use cases, but only the important ones. You will further refine these models and add more details later. In other words, keep it simple for now and refine/expand in the next iteration.
This is an example of a business process model using a Cross Functional Flowchart (I recommend this template). I have posted a real business process model provided by Deloitte Consulting using Cross Functional Flowcharts on Blackboard.
Prepare initial list of system actors and prepare the respective Actor Specification cards. Pay special attention to actors' goals, which will help you identify use cases (template #2,3). Important, since this is the beginning of the requirement process, you may want to identify ALL the primary actors of your system (i.e., those that derive value from the system). It is better NOT to include secondary actors at this point because these are usually discovered along the way and can be included later on.
Prepare a brief description of the Scope of Work by listing and briefly describing all the important business events (e.g., an order is placed, a product is returned, etc.) that your client wants you to automate.
Use the actors and business events identifide above to prepare an initial Context Diagram.
Prepare an initial Use Case
list for
the business events/processes you have described above. Keep this
list short for now and only list the main use cases that will handle
the main functionality needed by your client. Include this list
in the main text and attach the corresponding "Initial"
Use Cases (using the appropriate form) in the appropriate
appendix. Business events/processes are related to Use Cases,
but this relationship does not have to be one-to-one. One business
event may lead to one or more Use Cases and more than one business
event may be merged into a single Use Case.
Note: a common mistake is to over.
An "Initial" Use
Case contains a text descriptions (6 to 8 lines) of what the
Use Case does. Descriptions must be clear, concise and informational,
and should provide a good idea of the functions handled by the
use case from the Actors' perspective. You will refine these
descriptions in the next deliverable.
A common mistake to avoid:
don't provide a long version the use case as the description (e.g.,
UC-100 Cash Withdrawal -- this use case allows clients to draw
cash from the ATM), but actually describe how the use case executes.
Prepare initial Project Glossary and begin defining terms that may need to be defined to reduce ambiguity (if any)
Prepare a brief description of relevant
facts and assumptions that you may have learned about (if any)
[Top] [Schedule]
Project Deliverable 3: Elaboration & Base Use Cases
Review and refine all your work submitted in prior deliverables. Expand and refine your BPM as needed. Refine and expand your list of actors as needed. Update you context diagram as needed. Refine and expand your list of use cases. Your Use Case descriptions need to be very thorough and more detailed at this point. I would expect to see a good 10 to 20 line description for each Use Case (depending on its complexity) providing sufficient information to start prototyping the system. Update your BP/UC transitional matrix as needed. By now, you should have a well defined system concept, a complete list of actors, a complete list of business events, a complete Context Diagram, a complete list of Use Cases, a complete set of initial Use Cases with detailed descriptions, and a more complete Project Glossary. However, you can always add more later on as you gather new information and as you further refine the requirements.
Now that you have a better understanding of the functionality required, describe the Product Scope and prepare a complete Use Case Diagram.
Expand your Initial Use Cases
into Base Use Cases by including:
pre-conditions, basic flow of events (i.e., "sunny-day" scenarios),
post-conditions and a brief description of alternative flow of events
(is applicable). You should have 8 to 10 use cases at this point. If
for some reason you have more than 10 use cases you only need to expand the
10 most central Use Cases (those
that are key to delivering value to the actors). Note: you
will prepare detailed alternative flows (where and if needed) in the next
iteration, so please DO NOT include any conditional flows at
this point, just focus on the "sunny
day" scenarios.
IMPORTANT: DO NOT create
duplicate use cases. Students often make the mistake of preparing new
Base Use Cases and leaving the Initial Use Cases in the same document.
This leads to confusion, inconsistencies and more work for you (and your
client and me). Simply copy your use case description from the Initial
Use Case form to the description field of a Base Use Case form, then
edit and simplify your description. Prepare your Base Use Case in this
form and REMOVE the
corresponding Initial Use Case from your document. Your client (and
instructor) do not want to see two use case forms for the same use
case, just the most updated one.
[Top] [Schedule]
Project Deliverable 4: Further Elaboration & Re-factoring, Extended and Included Use Cases
Review and refine all your work submitted in the prior deliverables.
Select TWO of the 6 most central Use Cases for which you developed Base Use Cases in the prior deliverable and expand them into an Elaborated Use Case by adding all necessary conditional flows (within the Base Use Case -- i.e., "rainy-day" scenarios), Alternative flow of events (in separate Alternative Flow Use Cases, indicating the respective "insertion points" in the Base Use Cases) and/or Extending Use Cases (if needed). These use cases should be the ones that provides the most critical functionality for the application and ones that have sufficient process complexity. The flows of events you describe need to be thorough and complete, handling every possible alternative and exception tha the system may encounter while executing this Use Case.
(Optionally) Re-factor your design by identifying flow of events that repeat across cases (if any), which can be extracted into Included Use Cases. If you find them, re-factor your use cases by adding "insertion points" in the Elaborated Use Cases where appropriate, and preparing the respective Included Use Cases. Again, re-factoring is optional because it should only be done if it makes sense. You may not have enough repetition of flows to justify re-factoring, but it may not be a bad idea to practice how to re-factor any way.
Prepare brief descriptions of all "noteworthy" non-functional requirements (Volere 10 through 17). Please keep in mind that this portion of the project is only worth 5% of your grade. The idea is for you to "briefly" describe a "few" "noteworthy" non-functional requirements. These should be obvious qualities that your system should have to provide value to its users (e.g., security, reliability, etc.) and other qualities described by your client. You can use the types of non-functional requirements listed in the project template or in the Volere template as a guide, but you don't need to include all these types, only the ones that are noteworthy. [Top] [Schedule]
Project Deliverable 5 -- Elaboration: Iteration E3 -- Data Objects and Database Conceptual Description
Review and refine all your work submitted in the prior deliverables.
Using the information in the Use Cases, identify all the data objects or database tables that your system will maintain. The intital set of tables you will identify will most likely need to be refined later. Database tables are identified in requirements descriptions by following (and boldfacing) the use of key "nouns". Nouns usually indicate possible data objects or entities that the system needs to gather and mange data for (e.g., invoices, clients, courses, students).
Using this information, prepare a CRUD (create, read, update, delete) table. This matrix should contain a list of all your use cases as rows and a list of all the tables (i.e., data objects) that you identified above. In the CRUD matrix, please identify with a C, R, U or D, which use cases create, read, update and/or delete records in which tables.
Using this information, prepare a list of all the tables that your database will maintain. You need to have at least 10 tables, but I recommend that you have no more than 12 tables to keep the project manageable. If you have more than 12 tables please consult with your instructor to see if your design can be simplified. Each of these tables should represent a person, business object or thing for which you want to collect data. Generally speaking, only a few of these tables (4 to 8) contain the main data, whereas the other ones contain lookup codes and other reference information.
In your table list, please include a brief paragraph describing each table. This paragraph should contain: (1) a general description of what the table is for and what a typical record in the table contains and (2) a listing of the most important attributes for each table (you don't need to describe all the attibutes in this description, just the most important ones -- you will be listing all attributes in your data model in the next iteration) -- e.g., “The Customers table will contain one record for every registered customer and will maintain contact, billing and shipping information about each of these customers."
From the CRUD matrix analysis, please describe in plain English 10 important queries that you will need to process create, read, update or delete operations identified in the CRUD matrix. You don't need to describe all operations in the CRUD matris, but only 10 of them. No need to prepare SQL queries at this point, just a PLAIN ENGLISH description of each query (e.g., list all orders for $1,000 or more, list all clients in the state of Maryland, list all order line items in which more than 10 units have been ordered). Each query must be identified with a number and a name, which you will later use when you write the corresponding SQL queries in MS Access.
Project Deliverable 6 -- Elaboration: Iteration E4 -- ERD and Relational Database Design
Review and refine all your work submitted in the prior deliverables.
Prepare a complete Entity-Relationship diagram for your database implementation, using MS Visio. This ERD must have all entities, relationships, cardinalities, minimum cardinalities, primary keys, foreign keys, and non-key attributes necessary for your database implementation.
Please copy and paste this diagram to your Project.doc document. Please do not post the actual MS Visio file.
Create all the necessary database tables using MS Access and name the file Project.mdb
Implement entity integrity in all tables (primary keys)
Implement referential integrity in all tables (using the relational design tool)
Implement update and delete rules as needed. All primary key updates must cascade to related tables (if any) and you need to decide which delete rules to implement, depending on what makes sense for business.
Implement business rules as necessary
Implement lookup pick lists for all foreign keys
Enter 5 to 10 test records in each table
Final Project Deliverable: Wrap-Up
Review and refine all your work submitted in the prior deliverables.
In addition to the database file, please update your Project.doc file and briefly describe your update rules, delete rules, and business rules. Also, please update the description of your queries to reflect the queries that you have implemented in the database.
Review all your files, documents and artifacts for consistency. Lack of consistency across parts of your requirements and design text, tables and diagrams is one of the most salient sources of confusion for your clients (and professor).
Enjoy!!