10 se core_applied_to_requirements

ERIK JONSSON SCHOOL OF ENGINEERING AND COMPUTER SCIENCENAVEEN JINDAL SCHOOL OF MANAGEMENTThe University of Texas at Dallas

Copyright © 2013, Lifecycle Management Innovations, LLC, All Rights Reserved



“Key” Element of Systems Engineering –

Systems RequirementsALIX MINDEN

SEPTEMBER 28, 2013



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013

SYSM 6301, “Key” Element of Systems Engineering – Systems Requirements

Slide 2of 47

Agenda

• Concept of Systems Requirements• Requirements Management Process (Theoretical)• Applying the “Core Four” to Systems Requirements• Requirements Management Process (Practical)• Applicable Systems Requirements Tools• Applicable Industries & Examples• Summary



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 3of 47

Concept of Systems Requirements –Overview and Purpose

• What are Systems Requirements?– Things desired/needed; what potential stakeholders / users

want the system to do.1

• Are there any other names for the Systems Requirements Process?– Requirements Engineering

• What is the purpose of Systems Requirements?– Foundation of system definition; forms basis for the

architectural design, integration, and verification.2

– Requirements Management



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 4of 47

Concept of Systems Requirements –Importance3

• SE is very important early in the lifecycle.

• Effective System Requirements are vital.

• Remember, ~80% of LCC is “baked-in” before PDR.

• PDR is BEFORE the actual development!



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 5of 47

Concept of Systems Requirements –Requirement Sources4



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 6of 47

Requirements Management Process –Overview of the Theoretical Process

• There are many different approaches.• The primary difference is the terminology.• Each approach utilizes the “core four” skills:

– Definition / Planning– Synthesis / Design– Implementation / Verification & Validation.

• We will focus on the INCOSE approach.– No popular approach is really better than the others.

– Analysis



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 7of 47

Applying the “Core Four”, Definition –Primary Focus Areas of Requirements Definition

• Identification of key system details.• Elicitation of stakeholder requirements.• Defining the CONOPS.• The human aspect of PM and SE.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 8of 47

Requirements Definition –Identification of Key System Details

• Document concept definition.• Document Interface definitions.• Define and document system constraints.• Identify and document system stakeholders.______

• What is a stakeholder?– “A stakeholder is any entity (individual or organization) with

a legitimate interest in the system.”5



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 9of 47

Requirements Definition –Requirements Gathering Issues6

Have you ever had this happen to you?



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 10of 47

Requirements Definition – Techniques for Stakeholder Requirements Elicitation

• Document Analysis.• Observation(s).• Questionnaires.• Interviews.• Stakeholder Analysis Workshops.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 11of 47

Requirements Definition –Requirement Elicitation Diagram7



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 12of 47

Requirements Definition –Defining the CONOPS

• A CONOPS is a series of use scenarios describing how the system is planned to be used / operated.

• Early a system lifecycle, its CONOPS is first defined, thereby starting to define its system requirements.

• In some environments, an initial CONOPS document is also called the Operational Concept Document (OCD).8

• Remember, the CONOPS also helps define the Measures of Effectiveness (MOEs).



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 13of 47

Requirements Definition –Requirements Gathering9

Have you ever see this scenario before?



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 14of 47

Requirements Definition –The Human Aspect of PM and SE

• Are all requirements known at the beginning of the definition of a system?

• Are all requirements logical and reasonable?• Do all requirements agree with each other?• “Do you know what you want, but have no ‘specs’?”10

All of these issues may be present because of humans.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 15of 47

Applying the “Core Four”, Analysis –Primary Focus Areas of Requirements Analysis

• Types of requirements.• Analysis approaches.• Types of analyses to perform.• Create modeling & simulation of possible

requirements.• Perform requirements trade-offs.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 16of 47

Requirements Analysis –Types of Requirements

• Business.• User.

• Functional.*– Process-Oriented– Information-Oriented.

• System.

• Non-functional.*– Operational– Performance– Security– Cultural / Political.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 17of 47

Requirements Analysis –Analysis Approaches

• What are the typical approaches to systems engineering analysis?– Top-down.– Bottoms-up.

• “…requirements definition and analysis is an iterationand balancing process that works both ‘top‐down’ (called allocation and flowdown) and ‘bottom‐up.’”11



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 18of 47

Requirements Analysis –Analysis Types to Perform12

• User requirements analysis.• CAIV / Lifecycle cost analysis.• Interface requirements analysis.• Requirement impacts analysis.

– Cost– Time

• Other SE impacts to Consider?

– Performance– Risk



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 19of 47

What factors are NOT analyzed when conducting a Lifecycle Cost Analysis?

• R&D Costs.• Supplier Investment Costs.• Utilization and Support costs.• Disposal costs.

• Why?



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 20of 47

Requirements Analysis –The System Proposal13




Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 21of 47

Requirements Analysis –What is the purpose of an N2 Diagram?14

• A graphical illustration of the relationships between various entities within a system.

• Used for Interface Requirements Analysis



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 22of 47

Requirements Analysis –Requirements Modeling & Simulation15

“Models ‘enhance’ the understanding of requirements.”16



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 23of 47

Requirements Analysis –Perform Requirements Trade-offs

• What is the difference between needs and wants?– A need is something the system must have.– A want is something that is “nice to have”.

• Always consider technical, time, and cost impacts to the O&S stage when performing requirements trades.

• System requirements need to be balanced in order to define a potentially feasible solution.

The first requirements set are wrong 99% of the time.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 24of 47

Applying the “Core Four”, Synthesis – Primary Focus Areas of Define & Design Requirements

• Modeling & simulation of requirements.• Key definitions and terms.• Establishment of important requirements details.• Conduct design trade-offs.• Prepare for functional analysis.• Will requirements be object-oriented?



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 25of 47

Define & Design Requirements –Buying a Swing.17




Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 26of 47

Define and Design Requirements –Modeling & Simulation of Requirements18

Once you have developed the model, you can start defining the system requirements.

Understanding and manipulating them is easier.

“Models ‘enhance’ the understanding of requirements.”



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 27of 47

Define and Design Requirements –Key Definitions and Terms19

• What does traceability mean?– Traceability is the linking of all requirements throughout

their decomposition and identification of verification methods.

• Other definitions you think are important, not already addressed?



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 28of 47

Define and Design Requirements –Establishment of Important Requirements Details

• INCOSE Characteristics of “Good” Requirements– Necessary– Consistent– Achievable

• I like the SMART approach as well.21

– Specific– Measureable

• All requirements use the word “shall.”

– Traceable– Implementation

independent

– Clear and concise

– Verifiable20

– Achievable– Realistic

– Time-Sensitive.21



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 29of 47

Define and Design Requirements –Conduct Design Trade-offs

• After each round of requirements analysis, the design requirements need to be reviewed.

• Many times, some of them needed to be traded away for various reasons.– Cost– Time– Performance

Trade-offs / Trade studies will be conducted regularly.

– Capability– Risk



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 30of 47

Define and Design Requirements –Prepare for Functional Analysis22

• What is a “function”?– A characteristic task, action, or activity that must be

performed to achieve a desired outcome. • What is a “functional analysis/allocation”?

– Functional Analysis/Allocation is an examination of a defined function to identify all the sub‐functions necessary to accomplish that function; all usage modes must be included in the analysis.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 31of 47

Define and Design Requirements –Will Requirements be Object-Oriented?

• What is it mean to be Object-Oriented?– System is decomposed into logical elements vs. functional.

• “Objects” are created using SysML to model the physical elements, behaviors, and relationships.23

System Diagram24

Class Diagram24

Logical Architecture24



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 32of 47

Applying the “Core Four”, Implementation – Primary Focus Areas of Rqmts Implementation and V&V

• Change management.• Requirements management plan.• Feedback loops and iterations.• Verification and validation.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 33of 47

Implementation, V&V of Requirements –Change (a.k.a. Configuration) Management25

• What is the purpose of Change Management?– Establish and maintain the integrity of all outputs/

deliverables and make them available when needed.• Inputs

– Configuration Items (CIs), a.k.a. deliverables.– Change Requests (CRs), requests to change a “baseline.”

• Outputs– Configuration management strategy and periodic reports.– Configuration baselines.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 34of 47

Implementation, V&V of Requirements –Requirements Management Plan

• Included in the Systems Engineering Management Plan (SEP or SEMP) should be the strategy for managing requirements.

• As discussed, two typical ways to manage requirements is by functional allocation or by object-orientation.

• The management approach needs to be documented and communicated effectively.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 35of 47

Implementation, V&V of Requirements –Feedback Loops and Iterations

• No complex system, or specifically system requirements, are created and finalized at one time.

• There are always multiple stakeholders to be involved.• There are always changes required.• Within the SEMP, include plans (& time in IMS) for:

– How to communicate with stakeholders and vice versa.– Who is responsible for what.– How changes will be managed and incorporated.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 36of 47

Implementation, V&V of Requirements –Verification and Validation

• What is an RVTM?– Requirements

Verification and Traceability Matrix.

• Why is it important?– It shows the mapping

of requirements to the verification methods that will be used.

Inspection Demonstration Analysis Test1.0 Subsystem 1 X1.1 Subsystem 1, Element 1 X

1.1.1 Subsystem 1, Element 1, Subelement 1 X1.1.2 Subsystem 1, Element 1, Subelement 2 X

1.1.2.1 Subsystem 1, Element 1, Subelement 2, Subsubelement 1 X


1.1.2.3 Subsystem 1, Element 1, Subelement 2, Subsubelement 3 X1.1.3 Subsystem 1, Element 1, Subelement 3 X1.1.4 Subsystem 1, Element 1, Subelement 4 X1.2 Subsystem 1, Element 2 X

1.2.1 Subsystem 1, Element 2, Subelement 1 X1.2.2 Subsystem 1, Element 2, Subelement 2 X


1.2.2.2 Subsystem 1, Element 2, Subelement 2, Subsubelement 2 X1.2.3 Subsystem 1, Element 2, Subelement 31.3 Subsystem 1, Element 3 X

1.3.1 Subsystem 1, Element 3, Subelement 1 X1.3.2 Subsystem 1, Element 3, Subelement 2 X2.0 Subsystem 2 X2.1 Subsystem 2, Element 1 X2.2 Subsystem 2, Element 2 X3.0 Subsystem 3 X

Verification MethodWBS Element Description



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 37of 47

Requirements Management Process (Practical) –General Requirements Considerations

• Although requirements should only use the word ‘shall’, many times ‘will’, ‘must’, and others are used.

• There is no “silver bullet” for SE requirements.• When determining requirements from “business

rules,” they are always “True or False”, regardless if a formal system is in place or not.

• With various flow diagrams, “alternate flows” are typically driven by the business rules.26



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 38of 47

Requirements Management Process (Practical) –Good Requirements Development27

• What should a “requirement” should look like?– Follow: “who” + “shall” + “verb/phrase” + “what”.

• “SE uses requirements to communicate the “vision” / need of the user/stakeholders to the developers.”

• INCOSE REWG has document for “decision criteria” for good requirements and set of requirements.

“Requirements engineering is the ‘backbone’ of SE.” Plan, analyze, and design requirements accordingly.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 39of 47

Requirements Management Process (Practical) –Bad Requirements Characteristics

• Have you ever heard someone say, “If we could just add this feature…”?– Frequently referred to as “gold-plating” the requirements.

• Bad Requirements typically include the following:– Use of negatives. (e.g. … no more than …)– Alternative ways to “meet” the requirement.– Multiple state condition requirements (a.k.a. compound).– Mandating the use of a “solution”.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 40of 47

Requirements Management Process (Practical) –Requirements and Traceability Verification28

• Traceability and designing to requirements, typical failures (meaning not feasible):– With timeline – With cost targets / budget / constraints– With technical capabilities and availability.

• RVTM Use:– Automate / Link Requirements to RVTM.– RVTM should drive the test plans and procedures.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 41of 47

Requirements Management Process (Practical) –Best Requirements Decomposition Approach29

• Take any SOW/A-Spec/item the customer gives you.• Break it down (out) to each sentence.• Rewrite each sentence in the format “X shall Y”.

– This will confirm your understanding of the requirements.– This will confirm your understanding of who does what.– This will confirm your understanding of who develops what.

Requirement Engineering to SE. Take the time to ensure you have the understand the requirements!



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 42of 47

Applicable Tools

• Microsoft’s MS Office Suite• IBM Rational’s DOORS (or Jazz)• Visure Solutions’ Visure Requirements.• Clear Case / Clear Quest (software requirements)

• Others?



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 43of 47

Applicable Industries / Examples30

• Automotive– Streamlining the demonstration of software compliance to

ISO 26262.– Multiple product lines with various levels of commonality.

• Medical Devices– Quickly and accurately demonstrate compliance to IEC

62304, FDA 21 CFR Part 820 and Part 11, or ISO 14971.– Minimize time to market.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 44of 47

Applicable Examples –Product Requirements Gathering31

How would requirements engineering fix this?



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 45of 47

Final Thoughts on Requirements Engineering

• Remember, a picture is worth a thousand words. • For those who will work with requirements gathering:

– Maintain an ever-growing list of questions to ask for requirements gathering!

• “Men go to far greater lengths to avoid what they fear then to obtain what they desire.32



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 46of 47

Summary –(1 of 2)

• Requirements Management terms of the “Core Four”?– Requirements Definition– Requirements Analysis– Define & Design Requirements– Requirements Implementation and V&V

• Remember, ~80% of LCC is “baked-in” before PDR. • PDR is BEFORE the actual development!• Gather requirements early, often, and effectively.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 47of 47

Summary –(2 of 2)

• Effective and complete requirements are needed to help ensure a successful system.

• Always consider HOW you will verify the requirement, when defining it.

• Remember, there are multiple ways to verify it. (IDAT)• Follow: “who” + “shall” + “verb/phrase” + “what”.• Human error is very easy, and can be expensive.• When possible, use software to automate & trace rqmts.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 48of 47

SYSM 6309 (SE 6361/CS 6361) –Advanced Requirements Engineering

• System and software requirements engineering. Identification, elicitation, modeling, analysis, specification, management and evolution of functional and non-functional requirements. Strengths and weaknesses of different techniques, tools and object-oriented methodologies. Interactions and trade-offs among hardware, software and organization. System and sub-system integration with software and organization as components of complex, composite systems. Transition from requirements to design. Critical issues in requirements engineering. (3-0)

• Prerequisites: CS/SE 5354 or consent of instructor



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 49of 47

For More Details, Refer Here.

• INCOSE Systems Engineering Handbook, version 3.2.2. See page 82.



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 50of 47

SOURCENOTES



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 51of 47

Source Notes (1 of 6)1. Dictionary.com. (Retrieved 24 September 2013).

http://dictionary.reference.com/browse/requirements?s=t 2. INCOSE SE Working Group. “Description.” Chap. 4 In Systems Engineering

Handbook, 72-73. Version 3.2.2. 2011.3. Minden, Alixandré R., and Daphne Biddle. “What is Affordability?” In Southern

Methodist University’s EMIS 8305 Course. Fall 2012.4. INCOSE SE Working Group. “Figure 4‐4 Sources of Requirements.” Chap. 4 In

Systems Engineering Handbook, 77. Version 3.2.2. 2011. 5. INCOSE SE Working Group. “Description.” Chap. 4 In Systems Engineering

Handbook, 57. Version 3.2.2. 2011.6. Dilbert.com. 22 March 2003. (Retrieved 24 September 2013).

http://dilbert.com/strips/comic/2003-03-22/

http://dictionary.reference.com/browse/requirements?s=t




Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 52of 47

Source Notes (2 of 6)7. INCOSE SE Working Group. “Figure 4‐3, Requirements elicitation captures the needs

of stakeholders across systems boundaries.” Chap. 4 In Systems Engineering Handbook, 61. Version 3.2.2. 2011.

8. INCOSE SE Working Group. “Establish the Concept of Operations.” Chap. 4 In Systems Engineering Handbook, 67-71. Version 3.2.2. 2011.

9. Dilbert.com. 22 March 2003. (Retrieved 24 September 2013). http://dilbert.com/strips/comic/2002-02-20/

10. Williams, Jeffrey. “Introduction to Model-Based Systems Engineering.” In INCOSE TUTORIAL: Model-Based Systems Engineering Workshop. 21 September 2013. http://www.visuresolutions.us/c/document_library/get_file?uuid=98036bf1-db6a-4bf1-91bc-a0ab783245be&groupId=10826

11. INCOSE SE Working Group. “Requirements Analysis Concepts.” Chap. 4 In Systems Engineering Handbook, 77-78. Version 3.2.2. 2011.


http://www.visuresolutions.us/c/document_library/get_file?uuid=98036bf1-db6a-4bf1-91bc-a0ab783245be&groupId=10826



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 53of 47

Source Notes (3 of 6)12. INCOSE SE Working Group. “Figure 2‐7, Cost and schedule overruns correlated with

SE effort.” Chap. 2 In Systems Engineering Handbook, 18. Version 3.2.2. 2011.13. Dilbert.com. 28 July 1996. (Retrieved 24 September 2013).

http://dilbert.com/strips/comic/1996-07-28/14. Jenney, Joe. 22 March 2011. “Figure 6-27, A Matrix of Functions to Functions is an

alternate tool for defining internal and external interfaces among functions.” (Retrieved 25 September 2013). http://themanagersguide.blogspot.com/2011/03/tools-for-defining-and-verifying.html

15. U.S. Army, Office of the Assistant Chief of Staff for Installation Management. Date Unknown. “Service requirements modeling framework.” (Retrieved 25 September 2013). http://www.acsim.army.mil/rd/images/framework.png

16. See note 10.


http://themanagersguide.blogspot.com/2011/03/tools-for-defining-and-verifying.html

http://www.acsim.army.mil/rd/images/framework.png



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 54of 47

Source Notes (4 of 6)17. “IT Shambles”. 12 January 2013. “The Legendary Tree Swing Cartoon. Super-

concentrated Wisdom.” (Retrieved 29 August 2013). http://itshambles.wordpress.com/18. See note 10.19. INCOSE SE Working Group. “Allocate Requirements and Establish Traceability.”

Chap. 4 In Systems Engineering Handbook, 92-95. Version 3.2.2. 2011.20. INCOSE SE Working Group. “Characteristics of Good Requirements.” Chap. 4 In

Systems Engineering Handbook, 78-81. Version 3.2.2. 2011.21. Wikipedia.org. (Retrieved 25 September 2013).

http://en.wikipedia.org/wiki/SMART_criteria22. INCOSE SE Working Group. “Overview.” Chap. 4 In Systems Engineering Handbook,

157-162. Version 3.2.2. 2011.

http://itshambles.wordpress.com/

http://en.wikipedia.org/wiki/SMART_criteria



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 55of 47

Source Notes (5 of 6)23. Ryder, Chris. Date Unknown. “Introducing Object Oriented Systems Engineering

Methods to University Systems Engineering Curricula.” http://www.dtic.mil/ndia/2006systems/Thursday/ryder.pdf

24. Hsu, John C., and J. Mike McDonough. Date Unknown. “Introducing Object Oriented Systems Engineering Methods to University Systems Engineering Curricula.” http://sse.stevens.edu/fileadmin/cser/2004/papers/332-Paper142.pdf

25. INCOSE SE Working Group. “Overview.” Chap. 5 In Systems Engineering Handbook, 228-231. Version 3.2.2. 2011.

26. Stinson, Marcia. “10 Things about requirements engineering you were afraid to ask.” In INCOSE TUTORIAL: Model-Based Systems Engineering Workshop. 21 September 2013. http://www.visuresolutions.us/c/document_library/get_file?uuid=d70a5df0-c996-4a6c-b4f3-cea20cf03983&groupId=10826

27. See note 10.

http://www.dtic.mil/ndia/2006systems/Thursday/ryder.pdf

http://sse.stevens.edu/fileadmin/cser/2004/papers/332-Paper142.pdf

http://www.visuresolutions.us/c/document_library/get_file?uuid=d70a5df0-c996-4a6c-b4f3-cea20cf03983&groupId=10826



Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 56of 47

Source Notes (6 of 6)28. See note 10.29. See note 10.30. VisureSolutions.US. (Retrieved 26 September 2013). http://www.visuresolutions.us/31. Dilbert.com. 9 May 1997. (Retrieved 24 September 2013).

http://dilbert.com/strips/comic/1997-05-09/32. Brown, Dan. Da Vinci Code. 2009.

http://www.visuresolutions.us/




Fall 201310/12/2013 SYSM 6301,



Fall 201309/28/2013


Slide 57of 47

BACKUP

10 se core_applied_to_requirements

Engineering

systems requirements

requirements engineering

dallas copyright

university of texas

effective system requirements

architectural design

potential stakeholders

actual development