Updated the Table of Contents>
Project Requirements Specification
Project Name:
Team Members
Client Contact:
Professor: J. Alberto Espinosa, Kogod School of Business, American University
Last updated:
Deliverable Number: <#>
Document Revision Number: <#>
-
Save a copy of this document as is with the name “ProjectTemplate.doc” (or .docx) and keep it as a reference. It contains all the instructions you will need to complete the project.
-
Save another copy of this document with the name “Project.doc” (or .docx) and remove the word and all other text within and template instructions (like this one). Also, please remove all the blank forms at the end of this document. All this information is for your benefit, but should NOT appear in your own project document.
-
In other words, your final project document should look and read like a real requirements document as you would submit it to a business client. So, it must have a businesslike appearance, including: well formatted graphics and tables, clear and concise text that is readable, informational and free of typos and grammatical errors.
-
All project documents must have a cover page like this one. Every revision of this document must have all the information shown on this sample cover page.
-
The sections in the document must be numbered (consistent with this template) to facilitate communication with your client (and your professor) about the specifics of your document.
Table of Contents & Status Report
|
Project Component
|
% Done
| -
Introduction
|
|
System Concept
| -
Business Case and Project Vision
|
| -
Stakeholders
|
|
Business Process Requirements
| -
Business Process Analysis
|
|
System Requirements
| -
System Actors
|
| -
Functional Requirements
|
| -
Non-Functional Requirements
|
| -
Mandated Constraints
|
| -
Relevant Facts and Assumptions
|
|
Information and Data Requirements
| -
Data Entities and Relationships
|
| -
Visual Model
|
|
Appendices
| -
Glossary of Terms and Acronyms
|
| -
Business Process Model
|
| -
Actor Cards
|
| -
Use Case Diagram
|
| -
Transitional Matrix: BPM and Use Cases
|
| -
Use Cases: Functional Requirements
|
| -
Data Model
|
| -
Transitional Matrix: CRUD
|
|
Communication Log
|
Date
|
Communication Topic
|
Comm
Type
|
Participants
|
Team Members
|
Client Reps
|
Other
|
Deliverable 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deliverable 2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deliverable 3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deliverable 4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Final Project Deliverable, Visual Simulation and Presentation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Communication Topic column enter a brief (just a few words) description of the main topic. In the Comm Type column enter either: Meeting, Skype, Phone, Email, etc. In the 3 Participants column indicate who attended the meeting or who handled the communication. The expectation is that you would have at least a couple of substantial communication interactions with your client for each deliverable.>
<IMPORTANT NOTE: students often make the mistake of writing this specification document in future tense (e.g., the system will allow users to withdraw cash). This has two problems. First, it increases the amount of work you have to do because once the system is finished you will use this document as part of the technical documentation of your system, which needs to be in present tense. Second, it makes the document harder to read. A well written document in present tense will help you accomplish the main goal of this document: to clearly and concisely document system requirements. So, please write in present tense.>
“Volere Requirements Template” (posted on Blackboard) recommended by the Atlantic Systems Guild, Inc. company, fully described by Suzanne Robertson and James Robertson in their book: “Mastering the Requirements Process” (please note that Tom DeMarco, one of the most influential members of the software engineering community, is a principal of this company). The Volere process is a popular requirements process used by several companies. We will not use this process for this project because we will be following both, the Unified Process (UP) of system development, which is a more standard process used these days, and the use case Process recommended by Frank Armour in his textbook, which is consistent with the UP. However, the Volere process includes a very useful requirements template that shows how a typical requirements document should be structured. Because this template is voluminous, the requirements template we will use for this course (subject of this document) is an adapted and simplified version of the Volere template. You can learn more about the “Volere” Requirements Process and associated resources at http://www.volere.co.uk/.>
< Note: an important aspect of client documents (or any document for that matter) is that every figure, table, exhibit and appendix in your document should be referenced in the main text. Any exhibit not referenced in the main text only causes confusion with your readers. Readers will wonder what to make out of unreferenced tables and figures, which are extremely confusing. In the case of key artifacts in appendices (BPM's, use case diagrams, data model), you need to not only to reference them in the main text, but also to provide a brief textual description of the artifact to orient your readers and introduce them to the artifact they are about to see in the appendix.>
-
Introduction
<“In this document we describe the requirements for the system [insert your project name here]. We first describe the system concept and vision, followed by a description of actors, system boundary and scope of the system. We then provide more detailed requirements using use cases, followed by a description of non-functional requirements for the system. Finally we provide a data model and other information management specifications. Please refer to Appendix A for a glossary of terms and acronyms used in this document.”>
-
Business Case and Project Vision
At minimum, this section should contain:
Deliverable 1:
-
A description of who your client is (important note: don’t refer to your clients by name in this section. Client reps sometimes change, so it is better not to use their names inside the document, just in the cover page.) Simply name the company and/or division/department you are doing this for and briefly describe your client’s business.
-
A statement describing the business problems/needs of your client, which will be the focus of your analysis on this project. Don’t state this problem in terms of system needs, but describe this as a business case. Why is this important to your client’s business? Be very specific here – this is the reason why you are being hired by your client as a consultant, so make a good case.
-
A brief overview of the present business processes (i.e., baseline) and functions associated with the problem you just described above. Don’t describe the entire process, but only those parts that are associated with the problem. Remember that there is a full business process section later in the document. This is just a brief overview.
-
Provide a brief discussion of the goals and objectives of the system you will be proposing. Focus on how the proposed system will address your client’s needs discussed above. At this point you don’t know precisely how the system will work, but you should have a good idea of how the system will solve your client’s problem. This is a high level overview, not a detailed description so be concise, but informational. You will describe your system in more detail later.
-
Any other pertinent background information.>
Deliverable 2:
-
Provide a brief overview of the proposed business processes (i.e., target process – only if it is different than the baseline). Don’t describe the entire process, but only those parts that are associated with your proposed solution. Remember that there is a full business process section later in the document. This is just a brief overview and it is a reduced version of your target process description in section 4 below.
Deliverable 3:
-
Provide a brief overview of the proposed system functionality of your solution. Describe which functionality will support your recommended target process and solution. Don’t describe the entire functionality, but only highlights of the key (not all) actors and functionality worth highlighting to a busy manager reading this. Remember that there is a full section for the functional requirements later in the document. This is just a brief overview and it is a reduced version of your functional requirements description in section 6 below.
Deliverable 4:
-
Provide a brief overview of the data objects supporting your solution. Don’t describe the entire data model, but just the key aspects of the data objects supporting your solution. Remember that there is a full section for the data requirements later in the document. This is just a brief overview and it is a reduced version of your data requirements description in section 10 below.
Final Project Deliverable:
-
Review everything you have written in this section and fine tune as needed. This section is what will sell your project to clients and high level managers, so it MUST be well articulated, understandable, cohesive, accurate, consistent and convincing. Many busy managers and clients will not have the time to review all your artifacts, but they will read this section carefully. It must be tight or you will never sell your project to your audience.
-
Closing statement. Connect everything back to the business case. Now that you have provided an overview of the business case, current process, process improvements, new functionality, etc., you are in a good position to provide a more impactful statement of the tangible benefits of your project implementation and how it helps business. Any quantification you may be able to provide here would be most useful (e.g., increased revenues, increased profits, reduced costs, efficiencies gained, quality improvements, reduced personnel effort, more reliable and timely information, etc. You don’t need all these, but think carefully about the specific business value your implementation is providing to your client)
-
Stakeholders
< The stakeholder analysis section should contain a list of all stakeholders associated with your system. For each stakeholder, you need to provide: (1) a description of the stakeholder role and/or stake with respect to the system. This description should not contain person name names, but roles (in case the people involve change); and (2) a description of how the stakeholder is affected by the system or what is his/her vested interest in the system.
Please note that all sections associated with artifacts in appendices must have a brief text narrative providing an overview of the artifact. This narrative should contain, at the very least: (1) a brief overview of the artifact (not a full articulation of the artifact); and (2) any information necessary for your readers to understand the artifact. Some artifacts cannot be understood without some brief explanation of notations or symbols used, so this narrative is critical to the effective understanding of what you are trying to illustrate in the artifact.>
-
Business Process Analysis
“scope of work”. It does two important things. First, contains an articulation of your client’s present (i.e., baseline or as is) business process and your proposed (i.e., target or to be) business process improvements. Second, and equally important, it “bounds” the scope of your work for this client engagement. Often the complete process is much larger than what you are describing here. By articulating the baseline and target business processes, you are in essence establishing boundaries for the scope of your work on this project. This section needs to have at least 3 sections:
-
Baseline Process – Provide a narrative overview of the current (baseline) business process. This description should be brief and high level paragraph, but should also be informational. Describe how things are currently done. Do not focus on the current system, unless the system is integral to the process. Focus instead on the work being done by individuals. This description should be accompanied by a baseline BPM in Appendix B1 and this BPM should be consistent with your text description in this section. At the end of your text description, you need to reference the corresponding appendix, e.g.,
“For further details on the baseline BPM, please refer to Appendix B1.”
Please ensure that your text narrative description in the main text is consistent with your BPM diagram. Imagine that you want to briefly describe your BPM to someone over the phone. That’s what your narrative should say. This model should NOT contain a lot of details (it should fit on one page), but should give the reader a broad overview of the current business processes related to this implementation. Do NOT include any process improvement recommendations at this time. Just focus on understanding the current business processes. A Deloitte client once provided this description of the baseline BPM, which sums it up quite nicely: “the baseline BPM you deliver represents your demonstrated understanding of your client’s business”, which will boost your client’s confidence in your work.
All BPM’s in this document need to have a functional band (i.e., swim lane) for each main user type, role, business unit, department or function involved with the processes you are automating. Remember, this is a model of the key BUSINESS processes and not a system model. You need to model what people do, NOT what the system will do. These diagrams are useful to foster clear communication with your client (and professor) and to develop a shared conceptualization of the work to be done within your team. Important: your project vision and client problem description need to make reference to and be consistent with this baseline BPM (otherwise, why model it?).
-
Process Analysis – An analysis of the problems and bottlenecks in the current process just described. This section should be one or two paragraphs long in which you identify the pain points, inefficient steps, redundant steps, wasteful loops, etc. This description should NOT be focused on what a system does or will do. However, since the objective of your client assignment is to develop specifications for a system, the capabilities that computerized systems bring about should be in the back of your head as your formulate recommendations. You need to analyze each process step, decision step, flow between steps, phases, and functional bands, and analyze things like:
-
Are there any steps that could be eliminated? Eliminating steps are not always possible or even useful and you have to be careful that this is OK with your client. But you may have identified steps that will not be necessary with a new process or a new system, or perhaps there are wasteful or inefficient steps that can be eliminated.
-
Are there any steps that could be added? Removing steps may simplify the diagram, but sometimes adding a few steps can make things more efficient. For example, you could add a step that collects customer data, that can later be used for analysis.
-
Are there any steps that could be split into more than one step? Sometimes, a simple step doesn’t do the job and you need to add steps.
-
Are there more than one step that could be merged? Sometimes multiple steps can be simplified and consolidated into a single step to gain efficiencies.
-
Can steps be re-routed to other individuals or functional bands, or perhaps re-ordered to make things more efficient.
-
Are there steps in which efficiencies could be leveraged from IT? Again, your focus at this stage is not in IT per se, but you may want to think about how IT can help you improve the process.
-
If your solution requires that the target BPM be identical to the baseline BPM, use this section to articulate the process improvements that automation and computerization of the process will bring about. For example, if a particular government benefit application process has well defined steps that need to be followed, you may not be able to change the process. But you should be able to identify which and how manual steps, or which steps handled by antiquated systems will be better handled by the new system.
-
Finally and IMPORTANTLY, students sometimes make the mistake of simplifying the BPM, without simplifying the process itself. For example, someone may suggest merging two steps into a single step in the BPM drawing, but the work that needs to be done is the same. All this does is to change the visual representation of the work, but does not change the work itself. Please ensure that as you formulate your business improvement recommendations you are improving the work, not just the drawing of the BPM.
-
Target Process – A description of your proposed business process improvement. Your proposed improvement must follow from your analysis above (otherwise, why analyze?). If your solution does not change the current process, please specify that very clearly here. Often teams simply omit this section and silence can be very confusing. This description should be concise and very specific. Your BP improvements don’t necessarily have to be large and comprehensive. Sometimes small changes in focused areas bring about substantial benefits. If your improvement is very focused on a particular aspect of the process, you don’t need to diagram the full process. Just focus in the solution or improvement you are recommending, but provide some way of figuring out where you recommendation fits into the original process. Describe how things are currently done. This description should be accompanied by a target BPM in Appendix B2 and this BPM should be consistent with your text description in this section. At the end of your text description, you need to reference the corresponding appendix, e.g.,
“For further details on the target BPM, please refer to Appendix B2.”>
-
Your solution involves a business process improvement, but no change in the system. The solution is entirely based on improving the business process and how things are done, without altering the system. This would not be a good project for this course, but situations like this can happen in a real project. In this case, your target BPM is critical to your solution.
-
Your solution involves no change in the business process, but there are substantial efficiencies gained through automation. The business process does not change, either by choice or because it is not allowed by your client or by some regulation. In this case, you don't need to draw a target BPM, but you need to clearly articulate in the analysis and target BPM portion of this document that the target process is identical to the baseline process and why. Don't leave it up to the reader to interpret; or
-
The most likely possibility is that your solution involves some business process improvement combined with some automation. Because your solution involves a system implementation, this presents a unique opportunity to leverage the use of IT to improve the business process. When you go from a manual or older system, to a new system implementation, think of what aspects of the process could be redesigned to take advantage of the new system. In this case, you need to submit a target BPM and mark the steps that will be automated, to distinguish them from the manual steps.>
Share with your friends: |
