Software Engineering Project - Computer Science

Software Engineering Project ReportA Sample Document forGenerating Consistent Professional ReportsPrepared byJohn T. Bellfor use in CS 440at theUniversity of Illinois ChicagoSeptember 20131

How to Use This DocumentThis document is intended as a sample template that can be copied and edited to suit aparticular software engineering project. It was assembled from a combination ofdocuments [1], [2], and [3].StylesThis document was written in Microsoft Word, and makes heavy use of styles. Thestyles dialog is initially located on the menu bar under the “Home” tab in MS Word. It isrecommended that the styles dialog be pulled off into a separate window when workingon formatting of the document. If each paragraph is assigned a style, then modifying thatparticular style will affect all paragraphs in the document having the same style.The table of contents uses the document headings and sub-headings to automaticallygenerate table of contents information.Tracking Changes and Multiple AuthorsThe “Review” tab in MS Word contains several tools that are of particular use whenediting large documents, particularly when multiple authors are involved:The “Tracking” section allows you to track the ( proposed ) changes to a document, andto step through each proposed change to either accept or reject the proposed changes.The “Compare” section allows you to merge changes proposed by different authors, (which will be marked in separate colors for identification ), and then to use the changetracking tools described above to accept or deny each change.The recommended procedure is to start with each author having a copy of a basedocument, ( possibly this template. ) Then each author changes the section(s) they areresponsible for, and submits their changed version to one person who acts as the overalldocument editor. This author merges the changes, selectively accepts or rejects eachchange, and then distributes a new base document to all authors for the next round ofchanges. It is also possible to merge the changes and then distribute the document, sothat all authors can review the proposed changes. ( The latter approach may beappropriate for documents such as bylaws, in which the changes must be approved by acommittee or a vote before they can be accepted. )2

Dealing With Material that is Unwanted ( Right Now )Much of this document includes material that is not needed for every project, and/orwhich may not have been written yet, and so should be removed before printing ordistributing the document. There are several ways to do this, however each has theirdrawbacks:1. Delete the material completely. The drawback is that now it is completelygone, and the only way to get it back is to copy it from some other document,if that is even available.2. Change the font to "Hidden". The drawback is that this does not affect thenumbering of sections, either in the text or in the table of contents. Howeverthe original style information is retained, so when the text is unhidden,individual paragraphs do not need to be restyled.3. Change the style to "Hidden". This does cause the document to renumberproperly, ( because the paragraphs are no longer numbered paragraphs ), butall the original style information is gone, so if it is unhidden later, then all thestyles of all the unhidden paragraphs will have to be restored manually.4. Move the text, say to the end of the document, and then do not print ordistribute the material at the end of the document. If this is all that is done,then this material will continue to appear in the table of contents. However ifthe font is also changed to "hidden", then the material will not appear in theTOC, but all the original style information will be retained. The drawback tomoving the text is that now you need to keep track of where the informationwas moved from, in case you ever want to move it back.Hidden text can be made visible by selecting the backwards "P" paragraph mark on the"Home" tab.Table of ContentsThe table of contents lists the sections of the document and the page upon which eachsection starts. The table of contents may or may not include subsections, etc.Microsoft Word ( and many similar programs ) has the ability to generate a table ofcontents automatically from section headings, and to update it when the documentchanges. The table of contents included in this template is automatically generated byMS Word, and can be updated by selecting the table and clicking on the menu thatappears above the table at that time.Note: Remove all instructional materials before finalizing andsubmitting this document, including this entire page and theone before it.3

Table of ContentsHow to Use This Document . 2List of Figures. 9List of Tables . 10IProject Description . 121Project Overview . 122The Purpose of the Project . 122a The User Business or Background of the Project Effort. 122bGoals of the Project . 122c Measurement . 133The Scope of the Work . 133a The Current Situation. 133bThe Context of the Work . 143c Work Partitioning. 163dCompeting Products . 184Product Scenarios . 184a Product Scenario List . 184bIndividual Product Scenarios . 185Stakeholders . 195a5b5c5d5e5f5g6Mandated Constraints . 236a6b6c6d6e6f6g7The Client. 19The Customer . 19Hands-On Users of the Product . 20Priorities Assigned to Users . 21User Participation. 21Maintenance Users and Service Technicians . 22Other Stakeholders . 22Solution Constraints . 23Implementation Environment of the Current System . 24Partner or Collaborative Applications . 25Off-the-Shelf Software . 26Anticipated Workplace Environment . 27Schedule Constraints . 27Budget Constraints . 28Naming Conventions and Definitions . 297a Definitions of Key Terms . 297bUML and Other Notation Used in This Document . 304

7c Data Dictionary for Any Included Models . 308Relevant Facts and Assumptions . 318a Facts . 318bAssumptions . 31IIRequirements . 339Product Use Cases . 339a Use Case Diagrams . 339bProduct Use Case List . 349c Individual Product Use Cases . 3510Functional Requirements . 3511Data Requirements . 3612Performance Requirements . 3812a12b12c13Dependability Requirements . 4013a13b13c13d14Maintenance Requirements . 43Supportability Requirements . 43Adaptability Requirements . 44Scalability or Extensibility Requirements . 44Longevity Requirements . 45Security Requirements. 4515a15b15c15d15e16Reliability Requirements . 40Availability Requirements. 40Robustness or Fault-Tolerance Requirements. 41Safety-Critical Requirements . 42Maintainability and Supportability Requirements. 4314a14b14c14d14e15Speed and Latency Requirements . 38Precision or Accuracy Requirements . 39Capacity Requirements . 39Access Requirements . 45Integrity Requirements . 46Privacy Requirements . 47Audit Requirements. 48Immunity Requirements . 48Usability and Humanity Requirements . 4816a16b16cEase of Use Requirements. 48Personalization and Internationalization Requirements . 50Learning Requirements . 515

16d16e16f16g17Look and Feel Requirements . 5417a17b1821Cultural Requirements. 58Political Requirements . 59Legal Requirements . 6020a20bIIIExpected Physical Environment. 56Requirements for Interfacing with Adjacent Systems. 56Productization Requirements . 57Release Requirements . 58Cultural and Political Requirements . 5819a19b20Appearance Requirements. 54Style Requirements . 55Operational and Environmental Requirements . 5618a18b18c18d19Understandability and Politeness Requirements . 52Accessibility Requirements . 52User Documentation Requirements . 53Training Requirements . 54Compliance Requirements . 60Standards Requirements . 61Design . 61System Design . 6121aDesign goals . 6122Current Software Architecture . 6323Proposed Software Architecture . 6323a23b23c23d23e23f23g23h23i23jOverview . 63Class Diagrams . 63Dynamic Model . 63Subsystem Decomposition . 63Hardware / software mapping . 64Data Dictionary . 64Persistent Data management . 64Access control and security . 64Global software control . 64Boundary conditions . 6524Subsystem services . 6525User Interface . 656

26Object Design . 6526a26b26c26dIVObject Design trade-offs . 65Interface Documentation guidelines. 65Packages . 66Class Interfaces . 66Test Plans. 6627Features to be tested / not to be tested . 6628Pass/Fail Criteria . 6629Approach . 6630Suspension and resumption . 6731Testing materials ( hardware / software requirements ) . 6732Test cases . 6733Testing schedule . 67VProject Issues . 6734Open Issues . 6735Off-the-Shelf Solutions . 6835a35b35c36Ready-Made Products . 68Reusable Components . 69Products That Can Be Copied . 69New Problems . 6936a Effects on the Current Environment. 6936b Effects on the Installed Systems. 7036c Potential User Problems .

Software Engineering Project Report . This document is intended as a sample template that can be copied and edited to suit a particular software engineering project. It was assembled from a combination of documents [1], [2], and [3]. Styles This document was written in Microsoft Word, and makes heavy use of styles. The styles dialog is initially located on the menu bar under the “Home .