Term Project

Business Process Analysis

ITEC 630 Fall 2015

Prof. J. Alberto Espinosa

Last updated 8/21/2015

To be done in small teams of approx. 5 members (3 Grads + 2 Undergrads)

[Scenario] [Template] [Components] [Grading] [Deliverables: 1 2 3 4 5 Final]

Scenario and Background

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) identify a business problem; (2) gather business requirements for a system solution; (3) prepare the respective formal system requirements specification document for this solution; (4) develop the corresponding information model; and (5) develop a simple visual simulation of a key aspect of the system.

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.

Project Components

Note: this section just provides an overview of project components, NOT the deliverables. The specific project deliverables are listed below and their due dates are in the class schedule.

The project has several components, which student teams will develop in 5 incremental deliverables through out the semester, but the key components are:

1. Business Process Analysis

Business process analysis is at the heart of this course. Everything we do in this class has the objective of making business process improvements. Everything else supports your recommended solution. A key aspect of this is to understand the "business work" that needs to be handled by the new system. This involves business process modeling (BPM), and there are two main sequential steps:

(1) Understand and document the "baseline" or "as is" process-- i.e., how the business processes the work presently and ideintifying what are the problems associated with this baseline process. You really can't formulate a solution or make recommendations until you have understood your client's business, the specific problem you are trying to solve and the associated processes. Your job here is to prepare a "baseline BPM" and a brief text description of it. This first step helps you get there. A sound baseline BPM will provide your client assurance that you understand what they do. Once you have prepared a baseline BPM that is acceptable to your client, and only then, you can proceed to:

(2) Analyze the process and formulating a "target" or "to be" process, which is your recommendation for business process improvement. Your job here is to prepare a "target BPM" and a brief text description of it. Please note that in some cases your client will specify that the baseline business process should not be changed. This may be due to legal requirements, regulations or other procedural issues. If this is the case, you need to articulate clearly why you are not presenting a target BPM in your solution. 

2. Functional (and non-Functional) Requirements Analysis: System Use Cases

A central piece of your requirements specification will be the "use case" model you will prepare for the functionality of the business application that will support your process solution above. A use case model contains several use cases and each use case 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 as many use cases as are necessary to completely describe the functionality of your system. However, you will only be expected to fully elaborate the 6 most important use cases.

3. Data Requirements Analysis

Once you have modeled the business process and system functional requirements, your next job is to model the information structure that will contain all the necessary data to support the propsed application solution. Your data model should include as many entities as are necessary to support the entire functionality of your system. However, you will only be expected to include the 8 to 12 most important data entities that support the information needs of your system.  

4. Visual Interface Modeling

You will learn how to simulate key aspects of your proposed system so that you can give your client a visual preview of what your solution will look like on the screen. You will be trained on iRise Studio visual modeling software by iRise trainers. This training is very similar to what iRise's corporate clients receive and will give you a most valuable marketable skill.

Project Grading

Note: the project will be graded as a cohesive whole. Each team member's grade will be adjusted upwards or downwards depending on his/her contribution to the project. This adjustment will be based on a number of factors, including: (1) the instructor's assessment based on individual interaction with team members; (2) level of interaction activity with the client; and (3) a peer evaluation at the end of the semester.

Project Content (70 pts)

1. (10 pts) Well articulated and convincing system vision and business case section.

2. (15 pts) Quality of the content of the business process description and BPM diagrams

           (target and baseline BPMs) and the respective process analysis

3. (15 pts) System requirements specifications and use case model quality

        Use cases, use case diagram, actor specificatios cards, BPM/UC matrix, functional

           requirements description and analysis.

4. (15 pts) Content quality of the information requirements specifications and analysis

        Data entities and attributes support the functional requirements; relational properties

           are well implemented (normalized, primary and foreign keys, etc.); CRUD matrix well developed.

5. (10 pts) iRise simulation quality (e.g., key functionality was modeled, functionaly well illustrated,
        ease of use, professional look and feel, etc.)

6. (5 pts) Content quality of other specification components.
        e.g., Introduction, system vision, non-functional requirements, mandated constraints, etc.

Project Process and Presentation (30 pts)

7. (10 pts) Adequate and timely progress on deliverables

8. (10 pts) Clear descriptions, good writing style, no grammatical errors/typos, content quality,
        appearance, professional look and consitency across artifacts in the Project.doc document. 

9. (10 pts) Good information exchange with your client; client feedback; and effective final presentation

[Top] [Schedule]

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.

[Top] [Schedule]

Project Deliverables

General Information

All project work will be carried out in teams. Each team is responsible for working on their assigned projects and with the assigned clients during the semester. Each team needs to complete the project components listed above, but these components will be completed progressively in 4 deliverables throughout the semester and a final submission at the end. The 4 work-in-progress deliverable have very specific requirements listed below, which need to be turned in on a timely manner per the class schedule.

 All deliverables (except the visual simulation) will be submitted on a single term project specification document based using a template provided by your professor (on Blackboard). Only one student in each team is required to submit this document via Blackboard (but students can rotate who submits different deliverables). The document must be named Project_<TeamName or TeamNumber>.docx. Your team will start with an empty template and then update, refine and submit it 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. In addition, your team is required to maintain all the necessary MS Visio and iRise Studio files containing the necessary models and diagrams. These models and diagrams will be copy/pasted onto the Project_<TeamName or TeamNumber>.docx file, but the team needs to be able to provide all associated MS Visio files when requested by the instructor. All deliverables need to be submitted electronically through Blackboard.

Deliverables and the final project submission are due at midnight on the due dates listed in the class schedule (we will discuss these in class).  Late deliveries, and incomplete or inadequate deliverables will carry a substantial penalty towards your team's final project grade.

[Top] [Schedule]

Timeline 

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, and that process performance is strongly associated with final product peformance.

Your final project will be graded upon completion at the end of the semester.  But making timely and adequate progress in your deliverables is a grading component worth 10% of your final project grade. Your deliverables will not only allow your instructor to evaluate your progres, but also provide you with useful feedback to keep your project on track. Timely and adequate completion of deliverables not only accounts for good portion of your team's project grade, but frequent submission delays and incomplete deliverables are an indicator that the project is not going well, which may affect your final project grade in other ways. 

At the same time, your instructor understands that teams some times fall behind schedule for valid 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 deliverables listed below is outlined in the Class Schedule.

In each deliverable, you will start the required artifacts (e.g., diagrams, documents), but these artifacts don't need to be in their 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. For example, your first business process improvement recommendation may be incomplete initially and you may idintify key improvements in subsequent deliverables. So, it is perfectly OK to go back and refine your target BPM accordingly.

Deliverable Grades 

Each deliverable will receive a letter grade (A, A-, B+, etc.). These are not your final deliverable grades, but are meant to provide you with feedback on the quality of your deliverable. For example, if a team receives a B- in the first deliverable, but address all the concerns in their feedback will get their preliminary deliverable grade corrected. Teams that consistently ignore the instructor's feedback or do a mediocre job at addressing the issues raised will not get their deliverable grade improved and may actually receive a lower grade in the end.

[Top] [Schedule] 

Requirements for Specific Deliverables

Setup Before You Start:

• Download the Project Requirements Template from Blackboard or the web and save 2 copies. Name the first file Project_<TeamName or TeamNumber>.docx and the second one ProjectTemplate.docx. Keep the Project Template file as a reference for your project, with all the necessary instructions for each section. Open this file and review its contents and instructions carefully. It contains all the necessary sections and explanations for your project work.

• Use the Project_<TeamName or TeamNumber>.docx file as the project document for your team's deliverables. Open the file and first 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 submitting in your deliverables and also sharing with your clients from time to time, so please ensure that it is formatted properly, it is free of typos and grammatical errors, it has a businesslike and attractive appearance and it has none of my instructions in it. My instructions are for you, not for your client!!

• From this point forward, you are required to prepare and submit all your deliverables in this Project_<TeamName or TeamNumber>.docx document. Each 2 weeks or so, as you prepare your deliverables, you will be adding new information and updating/refining the existing information. Please include all the required materisl in the appropriate section of the project template and follow carefully the guidelines and instructions in the template for each section.

• Before you work on each section of the template, as required by the deliverables below, please read the instructions in the template very carefully. The instructions on what you need to do for each delivery are contained both, below in the deliverable instructions and in the template itself.

[Top] [Schedule]

Required for ALL deliverables:

• Status Report: please indicate the % completed for each section in each deliverable. For your convenience, I have the status report form in the table of contents. This will be very useful for your clients and professor to figure out which parts have changed from one deliverable to the next. When you complete a section, I suggest NOT entering 100%. Anything that is 100% complete is ready for grading and your client can critique you if there are things in that section that need to change. It is better to state a lower percentage, like 90%, which will indicate to your clients and professors that you are almost finished, but you are still fine tuning thing.

• Communication Log: you need to keep a log documenting your communication with your clients. For your convenience, I have placed the log form after the table of contents. This is a standard practice in consulting engagements and it is used for analysis (for future bidding on contracts) and for billing. By far, the most common problem mentioned by clients of this course is that the team did not communicate enough!!. I have never ever heard a complaint saying that the team communicated too much. How can a client trust your solution if they almost never heard from your team? Clients want to be sure your solutions are based on their real needs and requirements. So, please communicate with your clients as much as possible and document every communication. This will not only protect you if things go wrong, but will give your client assurance that you care about their problem and you are engaged. Please follow the instructions in the project template and log every email, phone call, Skype meeting, face to face meeting, etc. NOTE: you don't need to document your internal team meetings or your meetings with the professor, only the meetings and communication with your client.

[Top] [Schedule]

Project Deliverable 1: Business Case, System Vision and Baseline Business Process

• Your primary objective in this deliverable is to identify your client's problem and develop a system vision and overview of the current business processes your application will automate.

• Complete Section 1. Introduction of the project document.

• Complete Section 2. Business Case and Project Vision.

• Complete Section 3. Stakeholders.

• Complete the narrative for sub-section 4.1 Baseline Process and prepare a baseline BPM and copy/paste it into Appendix B1.

  [Top] [Schedule]

Project Deliverable 2: Business Process Recommendations, System Scope and Functionality

• The two main objectives for this deliverable are: (1) to describe and model your proposed business process improvements; and (2) to develop a high level overview of the functional scope of the system and a good understanding of the functionality needed by the system.

• Review and refine all your work submitted in the prior deliverable. In particular, ensure that your baseline BPM has been updated based on any new information you may have gathered since the last deliverable.

• Complete the narrative for sub-section 4.2 Scope of Work.

• Complete the narrative for sub-section 4.3 Process Analysis.

• Complete the narrative for sub-section 4.4 Target Process and prepare a target BPM and copy/paste it into Appendix B2.

• Complete sub-section 5.1 Primary Actors and prepare the corresponding actor cards for these actors in Appendix C.

• Complete the Initial Use Cases as described in Section 6. Functional Requirements. Prepare an initial use case for each use case you have identified, using the forms in Appendix F. Place all your use cases in that appendix. Ensure that the Elaboration Phase states "Initial Use Case".

• Complete the Use Case Diagram as described in Section 6. Functional Requirements and place your diagram in Appendix D.

• Complete the BPM/Use Case Transitional Matrix as described in Section 6. Functional Requirements and place the matrix in Appendix E.

• Now that you have completed all your functional requirements artifacts, complete the Functional Requirements Narrative and include it in the main text of Section 6. Functional Requirements

• Start Section 7. Non-Functional Requirements. You may not know many or any non-functional requirements a this time. Please do not include non-functional requirements simply because they would be nice to have (e.g., reliability, speed, user-friendliness). These are often very costly and they need to be discussed and approved by your client. Only write in this section the non-funtional requirements that you have learned about from your client.

• Prepare an initial Project Glossary (Appendix A) and begin defining terms that may need to be defined to reduce ambiguity (if any).

• Prepare brief description of mandated constraints, relevant facts and assumptions you may have learned about (if any) in sections 8 and 9.
  
  [Top] [Schedule]

• Your primary objective in this deliverable is to refine your use case model and develop a more detailed understanding of the main functionality of the system.

• Review and refine all your work submitted in prior deliverables. In particular, review, refine and revise/expand as needed your BPM, list of actors, use case list, use case diagram, use case descriptions, etc. Your Use Case descriptions need to be very more thorough and detailed at this point. I would expect to see a good 10 to 20 lines in each use case description, (depending on its complexity), providing sufficient information to start prototyping the system. Update your BPM/UC transitional matrix as needed.

• Review the priorities you entered in your initial use case forms in the prior deliverable and ensure that these priorities are accurate. Any use case that is critical to delivering the main functionality needed in the system should be rated "high priority".

• Select the 6 most central and high-priority use cases and further elaborate them into base use cases. DO NOT prepare new use case forms!! Use the forms you already started in Appendix F and elaborate these use cases. You only need ONE use case form for each use case number.

• Select no less than 3 of the most central use cases from the 6 base use cases you elaborated above and further elaborate them into elaborated use cases. Again DO NOT prepare new use case forms!! Use the forms you already started in Appendix F and elaborate these use cases. You only need ONE use case form for each use case number.
  
  [Top] [Schedule]

Project Deliverable 4 (and 4a): Information Analysis and Data Modeling

• Your primary objective in this deliverable is to develop a solid understanding of the data requirements to support the functionality described in your BPM and use case model.

• Project Deliverable 4a: You will find out that developing a data model from your functional requirements is not easy. Experience has shown that it helps to first develop a preliminary data model and then meet with your professor to discuss and refine your data model. This deliverable simply requires the team to prepare a data model in Visio and make an appointment with your professor. This is a mandatory step before completing the rest of Deliverable 4.

[Top] [Schedule]