SE 4351.001 Software RequirementsFall 2014

Process Specification

http://www.utdallas.edu/~axp120531/SE4352/Team Members

Joe Brownjsb100120

Desmond Leedcl102020

Giuseppe Mastrolorenzomxg106320

Michael Raibickmxr110530

Ryan Chenrxc109520

Robert Lockwoodrll092020

Blessing Osakueboo102020

Oscar Reyesoxr110330

Travis Chuntwc101020

Michael Muggermxm121531

Andrew Pohlmannaxp120531

James Williamsjxw110730

Bennilyn Quekbxq120430

Revision History

Date Version Description Author

11/11 1.0 Initial Team 1

11/14 1.1 Filled in Section 1 Management

11/18 1.2 Filled in Sections 2/3 Management

11/24 1.3 Updated IDEF Diagrams.Added ToC

Team 1

12/01 1.4 Final Check Management

1 of 21 v1.4

1 Introduction.........................................................................................................................3

1.1 Purpose...........................................................................................................................3

1.2 Scope..............................................................................................................................3

1.3 Stakeholders...................................................................................................................3

1.4 Definitions and Glossary.................................................................................................3

1.5 References......................................................................................................................3

2 Process Specification.........................................................................................................4

2.1 Spiral Methodology.........................................................................................................5

2.1.1 Weekly Process Flow Diagram.........................................................................................5

2.2 First Phase......................................................................................................................6

2.2.1 Requirements Elicitation...................................................................................................6

2.2.2 Requirements Analysis and Negotiation...........................................................................6

2.2.3 Requirements Specification.........................................................................................7

2.2.4 Requirements Validation.............................................................................................8

2.3 Second Phase.................................................................................................................9

2.3.1 Requirements Elicitation...................................................................................................9

2.3.2 Requirements Analysis and Negotiation...........................................................................9

2.3.3 Requirements Specification.........................................................................................9

2.3.4 Requirements Validation...........................................................................................10

3 Project Organization.........................................................................................................11

3.1 Project Phases..............................................................................................................11

3.1.1 Interim Phase I – Description: (8/28-9/9/30)...................................................................11

3.1.2 Final Phase I – Description: (9/31-10/16).......................................................................13

3.1.3 Interim Phase II – Description: (10/17-11/11).................................................................14

3.1.4 Final Phase II – Description: (11/12-12/05)....................................................................15

3.2 Traceability.......................................................................................................................16

3.2.1 IDEF0.........................................................................................................................16

3.2.2 IDEF1.........................................................................................................................17

3.2.3 IDEF2.........................................................................................................................18

2 of 21 v1.4

1 Introduction

1.1 PurposeThe purpose of this document is to describe the development process that Team Total Recall used in order to generate the deliverables for the Total Recall software system. Team Total Recall used the Spiral engineering methodology to develop the requirements for the Total Recall software system, and will use this document to map the activities of that methodology to the activities of the team during the course of the system development.

1.2 ScopeThe scope of this document includes mapping of the Spiral engineering model phases to project team activities, as well as decomposing individual project phases and their iterations. Additionally, traceability of the deliverables throughout all project phases will be produced.

1.3 StakeholdersThe application userTeam Total Recall

1.4 Definitions and GlossaryPlease see the appendix document titled “Glossary.”

1.5 ReferencesPlease see the Appendix document titled “References.”

3 of 21 v1.4

2 Process Specification

4 of 21 v1.4

2.1 Spiral MethodologyThe Spiral methodology is a cyclical development model that iterates through four main development activities: Requirements Elicitation, Analysis and Negotiation, Testing, and Validation. The process starts with an initial inception period in which the initial project elicitation and requirements are received, and ends with a final system deployment period which is marked by production system deployment to the client.

2.1.1 Weekly Process Flow Diagram

5 of 21 v1.4

2.2 First PhaseAn initial PMP was drafted that outlined the project background, project goals, and deliverables. Additionally the organizational structures regarding teams and team identities were added. Lastly, all of the support tools and mechanisms were defined so that all team members were aware of their available resources to begin work with.

2.2.1 Requirements ElicitationTo begin the development process, Team Total Recall received a preliminary project elicitation and initial system requirements list from the client.

Additionally, some correspondence with the client was initiated to clarify aspects of the preliminary project elicitation and initial requirements list. At this point in the project, Management laid out the Problem (Communication issues caused by Stage 3 Dementia) and the system Goal (Solving Communication issues caused by Stage 3 Dementia). Using the Problem and Goal as qualifiers, Management then set the scope of the Total Recall Software System.

2.2.2 Requirements Analysis and NegotiationAnalysis was started on the preliminary project elicitation and initial requirements list under the pretense of looking for conflicting issues in the preliminary project elicitation and initial system requirement list with regard to the system scope.

All three teams involved in the development effort were assigned a category of issues. The categories of issues were the following: World [Domain, Stakeholder, Non-Functional Objective, and Functional Objective] and Requirement Specification [Functional Requirement, and Non-Functional Requirement.]

6 of 21 v1.4

After all three teams had completed their issue analysis, the WRS deliverable was started that included each team’s evaluation of their assigned issues with regard to the scope of the system. Each team documented their evaluation which included the original issue statement from the initial elicitation or requirement list, the reason for why the original statement was deemed to have issues (out of scope, vagueness, incompleteness, unsoundness, etc), possible solutions to solve the underlying issues with the statement, the decision taken to either modify the statement (or reject it entirely), and finally the rationale behind the decision taken.

After finishing issue analysis and negotiation, each team went back and generated improved understandings of their assigned categories of issues. The result of this further analysis was added to the WRS.

At this point, Management began traceability charts to ensure that all contents in the WRS were on target with the scope definition of the system.

2.2.3 Requirements SpecificationWith an improved understanding of the system scope reflected by in-scope Functional Objectives, Non-Functional Objectives, Functional Requirements, and Non-Functional Requirements, Management re-factored team identities into the following: An Architecture team, a UI/UX team, and a Testing / User Manual team.

The Architecture team generated specifications based upon the improved Functional Requirements as constrained by the Non-Functional Requirements and authorized by the Non-Functional Objectives and Functional Objectives.

The UI/UX team generated an initial wireframe prototype based on the improved Functional Requirements. An important distinction must be made that at this point in the project, the wireframe prototype was

7 of 21 v1.4

required to accurately reflect the improved Functional Requirements and nothing more.

The Testing / User Manual Team generated the user manual based upon use-cases discovered from improved understanding of the Functional Requirements.

2.2.4 Requirements ValidationForward and Backward Traceability modeling was used to test and validate requirements and specifications of the system. Traceability modeling is the process of mapping all elements of the WRS document and prototype to each other in a specific manner.

Forward Traceability was started from the Domain and Stakeholder Requirements in the WRS to the visual elements in the Prototype

Backward Traceability was used to validate all components in the Prototype back to their justifying Requirement(s) in the WRS.

8 of 21 v1.4

2.3 Second PhaseThe primary goal of Management throughout the second cycle was judicious vigilance relating to traceability amongst the WRS elements (DR, SR, FO, NFO, FO, NFR, and FR). Management’s belief about the chances of successful delivery of the software system was centered upon the undeniable fact that issues with requirements in the initial elicitation and analysis period generate nearly all of the pitfalls that bring projects to ruin. For this reason, all of the phases in the second cycle were concerned primarily with traceability amongst all elements in the WRS document and prototype as they would relate to the scope and primary Goal of the system

2.3.1 Requirements ElicitationNo new requirements were elicited at the beginning of the second cycle. As such, a review was conducted to ensure traceability between the Problem and the Goal of the system within the context of the prescribed Software System Scope.

2.3.2 Requirements Analysis and NegotiationBecause no new requirements were elicited, no new analysis and negotiation was conducted. However, the current requirements were reviewed to ensure their traceability to the Goal of the system. Additionally and importantly, the requirements were tested to ensure conformance to the Software System Scope.

2.3.3 Requirements SpecificationBecause no new requirements were elicited, no new specifications were generated. However, the current specifications were reviewed to root out implementation bias, out-of-scope system behavior, or behavior that did not contribute to the overall goal of the system.

9 of 21 v1.4

2.3.4 Requirements ValidationAll Requirements were validated through Forward and Backward Traceability. Successful validation was seen as the union between complete traceability between any Requirement in the WRS and its relevance as being part of the solution to achieving the Goal of the system.

10 of 21 v1.4

3 Project Organization

3.1 Project Phases

3.1.1 Interim Phase I – Description: (8/28-9/9/30)In the interim cycle of Phase 1 we received the preliminary project elicitation and initial system requirements list from Dr. Chung. Upon receiving these inputs, the Problem statement and system scope were established. With the system scope as an operating constraint, the Goal of the software system was then formulated. The PMP was updated to reflect the Problem, the Goal, and the Scope of the software system. The preliminary project elicitation and initial system requirements were then decomposed into Domain Requirements, Stakeholder Requirements, Functional Objectives, Non-Functional Objectives, Functional Requirements, and Non-Functional Requirements. Each team took on one or more of the above categories of WRS elements and cross-examined each element against the system scope and Goal of the software system. The WRS was updated to reflect these issues. Using these findings, each team formulated improved understandings of the original Domain Requirements, Stakeholder Requirements, Functional Objectives, Non-Functional Objectives, Functional Requirements, and Non-Functional Requirements. The WRS was then updated again to reflect the improved understanding of the above elements. Traceability was established to assure positive validation of WRS elements. Using the improved understandings of the Functional Requirements with respect to the accompanying Non-Functional Requirements, a preliminary prototype was drafted. Lastly, a Presentation was created to demonstrate the progress of Team Total Recall.

Goals❏ Establish the Problem Statement.

11 of 21 v1.4

❏ Establish the Goal Statement.❏ Establish the system scope.❏ Decompose the initial project elicitation and requirements list

into DR, SR, FO, NFO, FR, and NFR.❏ Update PMP, WRS❏ Generate preliminary Prototype❏ Generate preliminary PPT❏ Traceability Matrixes

Outputs❏ Evolving PMP❏ Evolving WRS❏ Evolving PPT❏ Preliminary Prototype Mockups

12 of 21 v1.4

3.1.2 Final Phase I – Description: (9/31-10/16)In the Final cycle of Phase 1, traceability testing of all WRS elements Domain Requirements, Stakeholder Requirements, Functional Objectives, Non-Functional Objectives, Functional Requirements, and Non-Functional Requirements was conducted to ensure compliance to the system scope and Goal of the software system. Upon compliance of all Requirements, the initial Specifications were then drafted. The preliminary prototype was updated to reflect the Specifications as opposed to the Requirements. A User Manual was then begun, based on the use-cases of the software system. The PMP was updated to reflect the Final cycle team schedules, as well as the deliverables. The PowerPoint was also updated to reflect the refined prototype, as well as the Specifications as opposed to the Requirements.

Goals❏ Validate all WRS elements through Traceability testing❏ Generate initial set of Specifications❏ Begin preliminary User Manual❏ Update PMP, WRS, PPT

Outputs❏ Evolving PMP❏ Evolving WRS❏ Evolving PPT❏ Evolving User Manual❏ Preliminary Prototype Mockups

13 of 21 v1.4

3.1.3 Interim Phase II – Description: (10/17-11/11)In the Interim cycle of Phase 2, the initial Specifications were refined and then finalized. With finalized Specifications in hand, design of the software system commenced. The architecture and the user interface of the software system were designed. The last half of the cycle was spent on developing the system and documenting progress of the development effort. A Vision Document template was chosen, as well as a Process Specification Document. Lastly, a general Appendix was drafted. The Appendix contains commonly referred-to documentation.

Goals❏ Finalize WRS.❏ Design software system.❏ Implement software system.❏ Choose Vision Document❏ Update PMP❏ Update WRS❏ Update User Manual.❏ Begin Appendix.

Outputs❏ Evolving PMP❏ Evolving WRS❏ Evolving Vision Document.❏ Evolving Process Specification Document.❏ Evolving User Manual❏ Evolving Appendix❏ Alpha-quality Prototype

14 of 21 v1.4

3.1.4 Final Phase II – Description: (11/12-12/05)In the final phase of this project, all deliverables will be finalized, if not already finalized. A primary focus in this phase was documentation, as the software system was developed into a functioning mockup capable of demonstrating all activities as established by the use cases. With the prototype functioning well, the Vision Document was completed with the finalized Product Specification details and diagrams. The Process Specification document was updated to reflect the final phase’s activities, as well as process diagrams. The User Manual was finalized with prototype screenshots. The PMP was updated with finalized process scheduling and assignments regarding the teams. The Appendix was updated. Lastly, the software system was tested to ensure compliance with the activities derived from the use cases.

Goals❏ Finalize PMP.❏ Finalize Process Specification Document.❏ Finalize Vision Document.❏ Finalize User Manual.❏ Finalize Prototype.❏ Finalize Appendix.

Outputs❏ Final PMP.❏ Final WRS.❏ Final Vision Document.❏ Final Process Specification Document❏ Final User Manual.❏ Final Appendix❏ Alpha-quality Prototype

15 of 21 v1.4

3.2 Traceability

3.2.1 IDEF0

16 of 21 v1.4

3.2.2 IDEF1

17 of 21 v1.4

3.2.3 IDEF2

18 of 21 v1.4