Date post: | 07-Apr-2018 |
Category: |
Documents |
Upload: | sohail-arshad-khan |
View: | 216 times |
Download: | 0 times |
of 71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
1/71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
2/71
Course outline
Module 1 - Requirements Essentials
What is a requirement?
Where do requirements come from?
How are requirements recorded?
Process of collecting requirements
Quiz
Module 2 - Requirements Engineering process
Requirements Elicitation Requirements Analysis
Requirements Specification
Requirements Validation
Requirements Management & Traceability
Quiz
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
3/71
MODULE 1
Requirements essentials
Objectives What is a requirement?
Where do requirements come from?
How are requirements recorded?
Process of collecting requirements
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
4/71
What is a requirement?
In engineering, a requirement is a singular documented need of what a particularproduct or service should be or do.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
5/71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
6/71
Where do requirements come from?
Requirements
Usermodifications
User groupmeetings
Workshops
Prototypes
StudiesInnovation work
Questionnaires
Consultants &Trainers
Observation /Fieldwork
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
7/71
Why are requirements are important?
Designing and building an elegant computer program that solves the wrong problemserves no ones needs.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
8/71
Why are requirements are important?
Cost of finding bug is cheaper when compared with the same bug is found in thelater stage
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
9/71
How are requirements are recorded?
Use cases
Documents
Data dictionary
State diagrams
Scenarios
System diagrams
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
10/71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
11/71
Module 2
Requirements engineering tasks
Objectives RequirementsElicitation
RequirementsAnalysis
RequirementsSpecification
RequirementsValidation RequirementsManagement & Traceability
Quiz
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
12/71
Requirements Engineering Process
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
13/71
What Is Requirements Elicitation?
View
Art of listening to Stakeholders
Art of sending appropriate stimuli to stakeholders so that the responses are worth listeningto
The art of establishing an environment in which stakeholders are willing and able todescribe their problems and needs
Observations
Elicitation is the input to all system development
Elicitation technique varies greatly across projects
No one technique is universal
Completeness can never be assured
Lots of human nature and communication problems
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
14/71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
15/71
Requirements - Capture
Map out business
activities Build process flows for
key activities
Review business map
with stakeholders
map needs more work
Review scenarios
with stakeholders
scenarios agreed
Review process flows
with stakeholders
workflow needs more work
Build scenarios for key
activities where IT required
map agreed
scenarios need more work
Identify Use
Cases
workflow agreed
Review Use Cases
with stakeholders
Use cases need more work
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
16/71
Requirements - Elicitation techniques
To address the problems, the following techniques were discussed:
Interviewing and questionnaires
Requirements workshop Brainstorming and idea reduction
Storyboards
Use cases
Role playing
Prototyping
How do we choose the right technique for elicitation?
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
17/71
Elicitation Techniques : Interviewing
Simple direct technique : Personal substitute for questionnaire.
Pre Requisites for Interviewing:
Establish Customer or User Profile
Understanding the User Environment
Step 1:
Context-free questions can help achieve bias-free interviews
Goal is to prevent prejudicing the users response to the questions
Step 2:
Then, it may be appropriate to search for undiscovered requirements by exploring solutions. Step 3:
Convergence on some common needs will initiate a requirements repository for use duringthe project.
Step 4: Showtime
Assessing the Problem
Recap the Understanding
Analysts Inputs on Customers Problems
Assessing Your Solution (if applicable)
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
18/71
Interview Strategies :Structure of Interviews
Open-ended questions
Start with closed questions
Expands to
start with a general questions
end with a specific question
specific
general
specific
Diamond-ShapedDiamond-Shaped
FunnelFunnel
PyramidPyramid
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
19/71
Elicitation Techniques : Requirements Workshops
The requirements workshop is perhaps the most powerful technique for elicitingrequirements.
It gathers all key stakeholders together for a short but intensely focused period. The use of an outside facilitator experienced in requirements management can ensure
the success of the workshop.
Brainstorming is the most important part of the workshop.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
20/71
Role of the Facilitator
Establish professional and objective tone to the meeting.
Start and stop the meeting on time.
Establish and enforce the rules for the meeting.
Introduce the goals and agenda for the meeting.
Manage the meeting and keep the team on track.
Facilitate a process of decision and consensus making, but avoid participating in thecontent.
Make certain that all stakeholders participate and have their input heard.
Control disruptive or unproductive behavior.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
21/71
Workshop Agenda
Set an agenda before the workshop and publish it along with the other pre-workshopdocumentation.
Balance is the key, try to stay on the agenda, but do not strictly obey it, especially ifgood discussion is going on.
Order lunch in, and have a light working lunch.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
22/71
Requirements Elicitation Guidelines
Assess System Feasibility
Be sensitive to organizational and political considerations
Identify and consult system stakeholders
Record requirements sources
Use Business concerns to drive requirements elicitation
Look for domain constraints
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
23/71
Identify and Consult System Stakeholders
If lacking consideration of everyone who is likely to be affected by the introduction ofthe system, there is a great likelihood of missing some critical requirements.
Identifying stakeholders and discussing the system with them makes people feel likethey are part of the requirements elicitation process. In fact, it makes them a part ofit.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
24/71
Use Business Concerns to Drive Requirements Elicitation
If a system is to be useful, it must contribute to the key concerns of the business. Ifthe concerns are identified and used as drivers of the requirements elicitation process,
there will be higher confidence that the system will meet real organization needs.
Making the business concerns explicit helps to focus and clarify these goals.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
25/71
Collect Requirements from Multiple Viewpoints
If requirements are collected from a single viewpoint, they are unlikely to meet otherstakeholders requirements.
Collecting requirements from multiple viewpoints is a useful way to prioritizerequirements.
Identified viewpoints can be used to help
organize requirements elicitation and
organize the requirements specification, too.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
26/71
Elicitation Techniques : Brainstorming
Brainstorming
involves both idea generation and idea reduction
Is the most creative, innovative ideas often result from combining, seemingly unrelated ideas Rules:
Do not allow criticism or debate
Let your imagination soar
Generate as many ideas as possible
Mutate and combine ideas
Idea Reduction
Pruning ideas that are not worthy of further discussion
Grouping of similar ideas into one super topic
Prioritize the remaining ideas
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
27/71
Elicitation Techniques : Storyboarding
The purpose of storyboarding is to elicit early Yes, But reactions.
Storyboards can be positive, active, or inactive.
Storyboards identify the players, explain what happens to them, and describes how ithappens.
Make the storyboard sketchy, easy to modify, and unshipable.
Storyboard early and often on every project with new or innovative content.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
28/71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
29/71
Elicitation Techniques : Prototyping
Prototyping is especially effective in addressing the
Yes, But Syndrome
the Undiscovered Ruins Syndromes A software requirements prototype is
a partial implementation of a software system
built to help developers, users, and customers
better understand system requirements
Prototype the fuzzy requirements: those that, although known or implied, are
poorly defined and poorly understood
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
30/71
Interface to humans/userinterfaceUse prototyping, scenarios,modeling
Essential operating activitiesUse apprenticing, interviews,scenarios
Right selection of elicitation technique
Rigorous modeling of everything is likely not feasible
Prototyping everything is likely not feasible
Match requirements/analysis techniques to needs and situations
BusinessLogic
Interface
Information
Policy architecture, stored dataUse interviews, existing systemsanalysis
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
31/71
Requirements Analysis
Goals of requirements analysis and specification phase:
fully understand the user requirements
remove inconsistencies, anomalies, etc. from requirements document requirements properly in an SRS document
Analyst gathers requirements through:
observation of existing systems,
studying existing procedures,
discussion with the customer and end-users,
analysis of what needs to be done, etc.
After gathering all the requirements:
Analyse it:
Clearly understand the user requirements,
Incompleteness and inconsistencies
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
32/71
Requirements Modeling
Requirements modeling is more than an intuitive way of figuring out the functionalrequirements of a system. It is the application of a process of proven techniques to
produce useful and verifiable models.
Use Case modeling, Data modeling and UML (Unified Modeling Language) areexamples of Requirements Modeling methods.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
33/71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
34/71
Use Case
A meaningful piece of system functionality
Jakobson treats business processes as use cases of the business (a business is a
system too) More than a simple transaction (e.g. enter customer address)
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
35/71
Example
An ActorA Use Case
Change Invoice Add item to sales ledger
Chase Payment Issue Warning Letter
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
36/71
Example
Val idate
C u s t o m e r
Take O r de r
Detai ls
R e q u e s t
De l ivery Date
R ead O r de r D e t a il s ToC u s t o m e r
change r eques ted
de l i very date not acceptab le
C h e c k N u m b e r
W i th C us t om er
N o va l id num ber
cus t om er ag r ees
Trans fer Ca l l[ query fo r sa les team ]
C heck P r oduc t
C o d e
incor rec t p roduc t co de
R eques t C hange
of Order
c red i t lim i t exceede d
increase
cred i t
l imi t
r eques t
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
37/71
Prioritizing Requirements : Why it is important?
Projects cannot avoid the following fundamental facts of life:
Differences in importance
Limited project resources Long schedule
Small RE budget
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
38/71
What is priority ?
According to the Merriam-Webster Online Dictionary, the term priority means:
The state of being prior (i.e., given precedence in terms of date or time)
Given or meriting attention before competing alternatives Given preference
For them, prioritizing requirements means categorizing raw potential requirementsfrom the standpoint of importance into:
Essential requirements
Useful capabilities
Desirable capabilities
Based on the preceding, prioritizing real requirements could mean:
Prioritization by implementation order
Prioritization by importance
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
39/71
Challenges and Risks
Mandatory nature of requirements
Large number of requirements
Limited resources Quality requirements
Goals vs. requirements
Changing priorities
Incompatible priorities
Stakeholder and developer collaboration
Incompatible requirements
Lack of trust
Non-requirements
Subjective prioritization
Consequences of poor prioritization
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
40/71
Software Requirements Specification
Main aim of requirements specification:
systematically organize the requirements arrived during requirements analysis
document requirements properly The SRS document is useful in various contexts:
statement of user needs
contract document
reference document
definition for implementation
C
oncerned with the structure, quality and verifiability of the requirements document. Results in one document with 2 parts or 2 separate documents:
System requirements definition document
Software requirements specifications (SRS)
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
41/71
System Requirements Specification
Also known as User Requirements document
Also known as Concept of operations
It must list the system requirements along with background information about theoverall objectives for the system, its target environment & a statement of theconstraints, assumptions & non-functional requirements
Establishes the basis for agreement between the customers and the developers
Forces a rigorous assessment of requirements before design can begin
Provides a realistic basis for estimating product costs, risks, and schedules Provides an informed basis for transferring a software product to new users
Provides a basis for software standards
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
42/71
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
43/71
System Requirements
To be used efficiently, all computer software
Needs certain hardware components or other software resources to be present
Known as (computer) system requirements and Often used as a guideline as opposed to an absolute rule.
Most software defines two sets of system requirements:
Minimum
The 'Minimum system requirements' must be satisfied for the software to be usable at all
Computers with lower specifications than the minimum requirements may sometimes also run thesoftware
It is suggested, however, that the user will not have a representative experience of the software thisway. Generally this set is regarded more of a rule than a guideline
A system meetingthis requirement will provide basic performance of a software application
Recommended
Recommended system requirements are often suggested by Software Vendors for optimalperformance of a software
Although not a necessity, this set of requirements is often sought after by power users who expect togain a better experienceof software usability
Recommended System Requirements do not promise best possible performance of a software and aretreated as more of a guideline than a rule
Almost always a better system is available, or will be in future, to provide better performance. Also,exceeding by far these requirements does not guarantee to the user that everything will run withabsolute smoothness and look its best
More often than not, games are a bit disappointing in this respect, presenting issues that may or maynot be corrected with future modifications.
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
44/71
Hardware Requirements
The following are the various aspects of hardware requirements
Architecture
Processing power Memory
Secondary storage
Display adapter
Peripherals
Software Requirements deal with defining software resource requirements and pre-requisites that need to be installed on a computer to provide optimal functioning of
an application. Platform
APIs and Drivers
Web browser
Other requirements
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
45/71
Purpose of SRS
Contract Between Acquirer & Provider OfCapability
Defines what is to be provided
Establishes when and how things are to be provided Provides the Basis for:
Assessing proposed engineering changes
Resolution of acquirer/provider disputes
Development of test requirements
Preliminary user's manual
Maintenance & support planning
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
46/71
Scope of SRS
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
47/71
What makes a good SRS?
Points to be considered for producing a good SRS
Nature of the SRS
Environment of the SRS Characteristics of good SRS
Joint preparation of SRS
SRS evolution
Prototyping
Embedding design in SRS
Embedding Project requirements in the SRS
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
48/71
Benefits of SRS
SRS is useful as it helps us
to discover how to partition the system
to identify which requirements should be allocated to which components maintain is good communication between system users and system developers. It is the
requirements engineer who is the conduit for this communication
to acquire / possess technical skills
to have an ability to acquire an understanding of the application domain
to develop the inter-personal skills to help build consensus between heterogeneous groupsof stakeholders
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
49/71
SRS should refer to
Customers : deliverables which provide basis for development
Managers : scheduling basis and is a basis for measurement of progress
Designers : specifications for design
Developers : provide acceptable implementations
Maintainers : enables modification and enhancement
Users : for providing right look and feel, performance and behavior
QA : basis for process compliance
Testers : basis for validation, test planning and verification
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
50/71
Characteristics of SRS
Independent
Annotated
Concise Easy to Validate
Appropriate Abstraction Level
Testable
Correct
Unambiguous
Complete Verifiable
Consistent
Understandable
Modifiable
Traceable
f
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
51/71
Structure of a SRS
Introduction Purpose
DocumentConventions
Intended Audience
Reading Suggestions
Product / Project Scope
References
Overall Description Product Perspective
Product Functions
User Classes and Characteristics
Operating Environment
Design & ImplementationConstraints
Assumptions & Dependencies
External Interface Requirements User Interfaces
Hardware Interfaces
Software Interfaces
Communication Interfaces
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
52/71
Some Statistics
It costs 68 to 110 times more
to correct an requirement defect found by the customer rather than
to fix an error identified in requirement development activity
Time taken to fix a defect
30 minutes at the requirement development
5 to 17 hours to correct at System Testing
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
53/71
Objectives
Ensure the following:
SRS correctly describes the intended system behavior and characteristics
Software requirements were correctly derived from system requirements or other origins Requirements are complete
Requirements are of high quality
All views of requirements are consistent
Requirements provide an adequate basis to proceed with design, construction and testing
R i t R i C l
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
54/71
Requirements Review Cycle
Plan the
Review
Cycle
Obtain
Review
Comments
Classify & Sort
Comments
Conduct
Review
Meeting
Update
Requirements
Document
Execute
Agreed
Actions
Pre-review Baseline
All reviewers
work fromsame version
Post-review Baseline
Approved
version
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
55/71
Techniques
ReviewsInformal Reviews
Buddy ChecksWalkthroughFormal Technical Review
InspectionsHighest leveragesoftware qualitytechnique
Conducted beforethe baseline ofrequirementsisdevelopedParticipants
AuthorModeratorReaderRecorder
Stages
PlanningOverview MeetingsPreparationInspection MeetingReworkFollow-up Meeting
Entry CriteriaExit Criteria
Requirement Inspection Checklists
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
56/71
Requirement Review Challenges
Large Requirement Documents
Do NOT wait till the requirements are baselined
Perform incremental reviews during the development of SRS Start at different locations of the document to ensure complete coverage
Large Inspection Teams
Makes it difficult to schedule meetings
Difficulty to reach agreement on requirements and related issues
Geographic separation of reviewers
Collaboration is difficult
Communication costs and coordination is a very big issue
f l d
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
57/71
Software Requirements Validation
Concerned with the process of examining the requirements document to ensure thatit defines the right system:
Reviews
Prototyping
Model Validation
AcceptanceTesting
i
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
58/71
Requirements Management
Requirements
An activity that spans the whole software lifecycle.
It is fundamentally about change management and the maintenance of the requirements in astate that accurately mirrors the software to be, or that has been, built.
sIt includes change management, requirements attributes and requirements tracing
R i T bili
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
59/71
Requirements Traceability
Traceability is
one of the essential activities of good requirements management.
is used to ensure that the right products are being built at each phase of the softwaredevelopment life cycle, to trace the progress of that development and to reduce the effortrequired to determine the impacts of requested changes.
R i t Ch M t
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
60/71
Requirements ChangeManagement
General Patterns
Requirements changes usually cause all subsequent phases ( design, implementation, testing) change.
Any changes in subsequent phases may force requirements to change.
Every change introduced may potentially alter the requirements quality: consistency andcompleteness .
Changes can come Externally
The problem changed.
The users changed their minds or their perceptions.
The external environment has changed. The project team has no control over these external factors.
R i t Ch M t
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
61/71
Requirements ChangeManagement
Changes can come Internally
Misunderstandings in the RE process
Refining the understanding of the problem and possible solutions in the design phase Implementation limitations discovered during implementation
Defects discovered during testing or test case generation
Defects discovered during system operational lifetime
Wh t d it i l ?
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
62/71
What does it involve?
Change Control
ProposingC
hanges Analyzing Impact
Communicating
Making Decisions
Incorporation
Measuring Requirements Stability
Version Control
Identifying requirements document versions
Identifying individual requirement revisions
Wh t d it i l ?
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
63/71
What does it involve?
Requirement Tracing
Defining links to other requirements
Defining links to other system elements
Requirements Status Tracking
Defining requirements statuses
Tracking requirements that have each status
Change Control Process
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
64/71
Change Control Process
Benefits
Provides a formal mechanism to propose changes in requirements
Enables project leaders make informed decisions about the changes Lets you track the status of all proposed changes
Ensures that no suggested changes are lost or overlooked
Ensures funneling and filtering to ensure that most appropriate changes are incorporated
Change Control Policy
States expectations on how proposed changes to requirements will be handled
Change Control Process
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
65/71
Change Control Process.
Roles involved
Change
Control Board
Chair
Evaluator
Modifier
Originator
Project Manager
Request Receiver
Verifier
Change Control Process
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
66/71
Change Control Process.
Measurement ofChange activity
Requests received / open / closed Cumulative changes made, including added, deleted
Number of change requests originating from a source
Number of changes proposed and made in a given requirement baseline
Total effort involved in making the changes at various stages
Process for Managing Change
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
67/71
Process for Managing Change
A process for managing changes effectively must include the following steps:
Recognize thatC
hange is inevitable Baseline the requirements
Establish a single channel
Use a change control system
Manage change hierarchically
Change Request Diagram
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
68/71
Change Request Diagram
References
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
69/71
References
Websites :
http://www.westfallteam.com
http://www.processimpact.com http://www.vbhconsulting.com/
http://www.westfallteam.com/
White Papers :
Issues in Requirements Elicitation by Michael G Christel & Kyo C Kang
http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf
http://www.borland.com/resources/en/pdf/solutions/rdm_whitepaper.pdf
http://www.ee.unb.ca/kengleha/courses/CMPE3213/Requirements.htm
http://aaaprod.gsfc.nasa.gov/TEAS/lr-web/lindarose.html
Books:
Requirements Engineering: A Good Practice Guide: by Ian Sommerville, Pete Sawyer
Requirements Engineering by Elizabeth Hull (Author), Kenneth Jackson (Author), JeremyDick(Author)
References
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
70/71
References
http://www.ksc.com/education/oocourses/%60iterative.htm
Software Engineering Roger S.Pressman
Software Engineering - David Gustafson en.wikipedia.org/wiki/Software_requirement
Q?????
8/6/2019 MOD 1 ETI Essentials of Requirement Management CSlides RR 08082009
71/71
Q?????