Transcript Overview of Requirements Engineering

Requirements Validation
Section Four
Version: 1.0
Mehr 1383
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
1
‫نگاه اجمالي‬
‫‪.1‬‬
‫‪.2‬‬
‫‪.3‬‬
‫‪.4‬‬
‫‪2‬‬
‫تشريح مفهوم ارزيابي تشخيص نيازها‪ ،‬هدف از انجام آن‬
‫تعيين فاکتورهاي ارزيابي نيازها‬
‫بررس ي ويژگيهاي ارزيابي نيازها‬
‫بررس ي تکنيکهاي فرآيند ارزيابي نيازها‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
‫مجموعه پرسشها‬
‫‪.1‬اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟‬
‫‪.2‬چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟‬
‫‪.3‬تکنيکهاي اعتبارسنجي نيازها چيست؟‬
‫‪.4‬چه افرادي در جلسات بازنگري شرکت مي کنند؟‬
‫‪.5‬نقش نمونه سازي در اعتبارسنجي نيازها چيست؟‬
‫‪ .6‬نکات حائز اهميت در بازنگري نيازها چيست؟‬
‫‪3‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
‫راهنماي مدرس ( اسليدهاي ‪)10 -5‬‬
‫• مجموعه اسليدهاي اين قسمت به معرفي کلي ‪Verification and‬‬
‫‪ Validation‬مي پردازد‪ .‬علت نياز به ‪Requirement Validation‬‬
‫و سطوح مختلف تست سيستم در اين قسمت مورد بررس ي قرار مي گيرد‪ .‬و‬
‫هدف از ارزيابي نيازها و فاکتورهايي که در انجام اين فعاليت مطرح هستند‬
‫مشخص مي شود‪.‬‬
‫‪4‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
What is V&V?
What
• Purpose of V&V is to deliver a product that works
properly and performs to customer expectations.
• Verification is the process of confirming deliverable
hardware and software are in compliance with the
functional, performance, and design
requirements.(Have we built the system right?)
• Validation is the process of providing evidence that a
systems meets the needs of the User.(Have we built
the right system?)
What we are trying to do is to establish confidence in the
system, support equipment, test equipment, and people.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
5
V&V
• The definition of V&V encompasses many of the
activities that refer as Software Quality
Assurance (SQA).
• V&V encompasses a wide array of SQA
activities that include:
–
–
–
–
–
–
Formal technical reviews
Quality audits
Performance monitoring
Simulation
documentation review
testing
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
6
Design
Requirements
Different levels testing
Acceptance Testing
Validation Testing
Integration Testing
Code
Integration Testing
Unit
Testing
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
7
Requirements validation
What
• Concerned with demonstrating that the
requirements define the system that the
customer really wants. (Define the right
system)
• Pickup any problem before resources are
committed to addressing the requirements.
• Requirements error costs are high so validation
is very important
– Fixing a requirements error after delivery may cost
up to 100 times the cost of fixing an implementation
error
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
8
Relative Cost to Fix an Error
Phase in Which
Requirement is Found
Requirements
Cost Ratio
Design
3-6
Coding
10
Development Testing
15-40
Acceptance Testing
30-70
Operation
40-1000
Why
1
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
9
Requirements checking
What
• Validity. Does the system provide the functions
which best support the customer’s needs?
• Consistency. Are there any requirements
conflicts?
• Completeness. Are all functions required by the
customer included?
• Realism. Can the requirements be implemented
given available budget and technology
• Verifiability. Can the requirements be checked?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
10
‫راهنماي مدرس ( اسليدهاي ‪) 31-12‬‬
‫• در اين قسمت ويژگيهاي نيازهاي يک سيستم مشخص مي شوند و به اين‬
‫موضوع پرداخته مي شود که بررس ي نيازهاي سيستم بايد به صورتي انجام‬
‫گيرد که هر يک از نيازهايي که براي يک سيستم تشخيص داده مي شوند همه‬
‫اين ويژگيها را دارا باشند‪.‬‬
‫• دقت‪ ،‬کامل بودن‪ ،‬وضوح ‪ ،‬قابليت تست‪ ،‬ثبات‪ ،‬ارتباط با يک مشکل‬
‫مشخص‪ ،‬قابليت تغيير و قابليت پيگيري ويژگيهايي هستند که در اين قسمت‬
‫براي هر يک از نيازها و فرآيند مستندسازي و تعيين آنها معرفي مي گردند‪.‬‬
‫‪11‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
12
Correct
When
• Each requirement statement accurately
represents the functionality required of the
system to be built.
• Example (of an incorrect requirement):
• Problem domain (real life) states that
policeman ID numbers are in the range
[10000…) and
• the requirements document specifies that
each policeman has an ID number.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
13
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
14
Unambiguous
When
• The difficulty of ambiguity stems from the use of natural
language which in itself is inherently ambiguous.
• There is one and only one interpretation for every
requirement.
• Requirement statements should be short, explicit,
precise and clear.
• A glossary should be used when a term used in a
particular context could have multiple meanings (I.e. “the
user”).
• Formal requirements languages help reduce ambiguity.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
15
Unambiguous (cont.
)
How
• Example of ambiguity
– The TVRS shall store changes made in the details of
a traffic report as soon as the data is entered.
• Disambiguation:
– The TVRS shall store changes made in the details of
a traffic report if and only all input fields are valid and
user approved saving of data
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
16
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
17
Complete
When
• A requirements document is complete if it
includes all of the significant requirements,
relating to
–
–
–
–
functionality,
performance,
design constraints attributes
external interfaces.
• No sections are marked “To be determined”
(TBD).
• Conforms to the company standards.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
18
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
19
Testable
When
• A requirements document is testable (verifiable)
if and only if every requirement statement in it is
testable.
• A requirement is testable if and only if there is
some finite cost-effective way in which a person
or machine can check to see if the software
product satisfies that requirement.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
20
Testable (cont.)
How
• Example of a non-verifiable requirement:
– The TVRS shall complete storage of data within a
reasonable time of the user confirming a “Save”
sequence.
• Example of a verifiable requirement:
– The TVRS shall complete storage of data within 5
seconds of the user confirming a “Save” sequence,
80% of the time.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
21
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
22
Consistent
When
• Three types of conflicts:
– Different terms used for the same object:
• F323 and a “Policeman Details Form” might be
used to describe the same form.
– Characteristics of objects:
• In one part of the requirements document:
– “A policeman ID shall consist of decimal digits
only”,
• while in another part
– “Incase the policeman ID consists of nonalphanumerical characters, display an error
message”.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
23
Consistent (cont.)
When
– Logical or temporal faults: “A follows B” in one
part, “A and B occur simultaneously” in
another.
• “TVRS shall support removal of a policeman
record from the personal database” vs. “TVRS
shall support read-only access to policeman
details”.
Do clients know
what a database
is?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
24
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
25
Deal only with the problem
When
• Requirements should state “what” is required at
the appropriate system level, not “how”.
– In some cases, a requirement may dictate how a task
is to be accomplished.
• Avoid telling the designer “how” to do this job,
instead state “what” has to be accomplished.
• Requirements should be understood by the
clients as well as the developers.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
26
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
27
Modifiable
When
• A requirements document is modifiable if its
structure and style are such that changes can be
made easily, completely and consistently:
– Easy to use organization – table of contents,
index and cross references.
– No redundancy – a requirement should not be
in more than one place.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
28
Characteristics of requirements
•
•
•
•
•
•
•
•
What
Correct
Unambiguous
Complete
Testable
Consistent
Deal only with the problem
Modifiable
Traceable
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
29
Traceable
When
• Each requirement should be contained in a
single, numbered paragraph so that it may be
referred to in other documents:
– Backward traceability - implies that we know
where every requirement exists
• Each requirement explicitly references its source in
previous documents.
– Forward traceability – all documents to follow
will be able to reference each requirement.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
30
Traceable (cont.)
How
• Example:
– 2.1 Functional requirements:
• 2.1.1 TVRS initialization:
–…
– 2.1.15 TVRS shall display the user login window (see
section 2.1.2.2)
• 2.1.2 TVRS user interfaces:
– 2.1.2.1 All user interaction with the TVRS shall occur by
means of a graphical user interface.
– 2.1.2.2 User login window:
»…
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
31
‫راهنماي مدرس ( اسليدهاي ‪) 38-33‬‬
‫• مجموعه اسليدهاي اين قسمت تکنيکهايي که در فرآيند ارزيابي نيازها مورد‬
‫استفاده قرار مي گيرد را معرفي مي نمايد‪.‬‬
‫• بازنگري به عنوان يکي از تکنيکهاي ارزيابي در اين قسمت تشريح ميگيردد‪.‬‬
‫زمان انجام بازنگري‪ ،‬شرکت کنندگان در جلسات بازنگري و ويژگيهاي هر يک‬
‫از آنها و نکاتي که بايد در بازنگري مورد توجه قرار گيرند‪ ،‬در اين قسمت به‬
‫تفصيل شرح داده مي شود‪.‬‬
‫‪32‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Requirements validation techniques
•
•
•
•
What
Requirements reviews
Prototyping
Acceptance tests
Model Validation and Automated consistency
analysis
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
33
Requirements reviews
What
• Requirements review is a systematic manual
analysis of the requirements
• Regular reviews should be held while the
requirements definition is being formulated
• Both client and contractor staff should be
involved in reviews
• Reviews may be formal (with completed
documents) or informal.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
34
General Guidelines for Review
What
• Good communications between developers,
customers and users can resolve problems at an
early stage
• Always conduct reviews in a meeting format,
although the meeting participants might prepare
some reviews on their own.
• Continuously check what is produced to make sure
the product quality is as high as possible.
Checkpoints are provided for this purpose; refer to
the checkpoints for each analysis activity.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
35
Roles in Review Meetings
Who
• a person has essential knowledge of the business or
technology domain and detailed knowledge of the
applied facilitation and modeling techniques:
– Requirements Reviewer
– Requirements Specifier
– System Analyst
• possibly at milestones such as the beginning or end of a
Phase:
–
–
–
–
Stakeholders - customers and end-users (Where possible)
Change Control Manager (Where reviewing Change Requests)
Test Designer (Optional)
Software Architect (Optional, usually in Inception and
Elaboration)
– Project Manager (Optional, usually at Phase Start)
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
36
Review checks
What
• Verifiability. Is the requirement realistically
testable?
• Comprehensibility. Is the requirement properly
understood?
• Traceability. Is the origin of the requirement
clearly stated?
• Adaptability. Can the requirement be changed
without a large impact on other requirements?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
37
RUP Checkpoints: Requirements Attributes
What
– Has the correct set of requirements attributes been used as specified in the
Requirements Management Plan?
– Have attributes been set up for each requirement type to account for the following,
where applicable, for each requirement?
•
•
•
•
•
Tracking status?
Benefit?
Rationale?
Level of effort to implement?
Type and amount of each type of risk involved in implementing?
– Schedule risk?
– Resource risk?
– Technical risk?
•
•
•
•
•
•
•
•
•
Stability of the requirement?
Target release?
Assignment?
Marketing input?
Development input?
Revision history?
Location?
Reasons for change?
Inconclusive requirements?
– Have all traceabilities been set up as specified for the project in the Requirements
Management Plan?
•Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
38
‫راهنماي مدرس ( اسليدهاي‪)60- 40‬‬
‫• نمونه سازي يکي از ابزارهايي است که در ارزيابي تشخيص صحيح نيازهاي‬
‫يک سيستم مورد استفاده قرار مي گيرد‪.‬‬
‫• دراين قسمت به معرفي نمونه سازي‪ ،‬مزايا و معايب آن‪ ،‬روشهاي مختلفي که‬
‫براي ساخت نمونه ها وجود دارد‪ ،‬ويژگيهاي هر روش‪ ،‬مورد استفاده آن و‬
‫ابزارهايي که در ساخت نمونه ها به کار مي رود ‪ ،‬پرداخته مي شود‪.‬‬
‫‪39‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Requirements validation techniques
•
•
•
•
What
Requirements reviews
Prototyping
Acceptance tests
Model Validation and Automated consistency
analysis
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
40
System prototyping
What
• Prototyping is the rapid development of a
system
• Using an executable model of the system to
check requirements.
• In the past, the developed system was normally
thought of as inferior in some way to the
required system so further development was
required
• Now, the boundary between prototyping and
normal system development is blurred and
many systems are developed using an
evolutionary approach
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
41
Uses of system prototypes
What
• The principal use is to help customers and
developers understand the requirements for the
system
– Requirements elicitation. Users can experiment
with a prototype to see how the system supports
their work
– Requirements validation. The prototype can reveal
errors and omissions in the requirements
• Prototyping can be considered as a risk
reduction activity which reduces requirements
risks
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
42
Prototyping benefits
Why
• Misunderstandings between software users and
developers are exposed
• Missing services may be detected and confusing
services may be identified
• A working system is available early in the process
• The prototype may serve as a basis for deriving a
system specification
• The system can support user training and system
testing
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
43
Prototyping benefits
•
•
•
•
•
Why
Improved system usability
Closer match to the system needed
Improved design quality
Improved maintainability
Reduced overall development effort
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
44
Prototyping in the software process
What
• Evolutionary prototyping
– an initial prototype is produced and refined
through a number of stages to the final
system
• Throw-away prototyping
– a practical implementation of the system is
produced to help discover requirements
problems and then discarded. The system is
then developed using some other
development process
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
45
Prototyping objectives
What
• Evolutionary prototyping
– to deliver a working system to end-users.
– The development starts with those requirements
which are best understood.
•
Throw-away prototyping
–
–
to validate or derive the system requirements.
The prototyping process starts with those
requirements which are poorly understood
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
46
Evolutionary prototyping
What
• Must be used for systems where the
specification cannot be developed in advance
e.g. AI systems and user interface systems
• Based on techniques which allow rapid system
iterations
• Verification is impossible as there is no
specification.
• Validation means demonstrating the adequacy
of the system.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
47
Evolutionary prototyping
Develop abstract
specification
Build prototype
system
What
Use prototype
system
N
Deliver
system
YES
System
adequate?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
48
Evolutionary prototyping advantages
Why
• Accelerated delivery of the system
– Rapid delivery and deployment are
sometimes more important than functionality
or long-term software maintainability
• User engagement with the system
– Not only is the system more likely to meet
user requirements,
– they are more likely to commit to the use of
the system
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
49
Evolutionary prototyping
How
• Specification, design and implementation are
inter-twined
• The system is developed as a series of
increments that are delivered to the customer
• Techniques for rapid system development are
used such as CASE tools and 4GLs
• User interfaces are usually developed using a
GUI development toolkit
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
50
Evolutionary prototyping problems
What
• Management problems
– If management processes assume a
waterfall model of development
– Specialist skills are required which may not
be available in all development teams
• Maintenance problems
– Continual change tends to corrupt system
structure so long-term maintenance is
expensive
• Contractual problems
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
51
Prototypes as specifications
What
• Some parts of the requirements (e.g. safetycritical functions) may be impossible to
prototype and so don’t appear in the
specification
• An implementation has no legal standing as a
contract
• Non-functional requirements cannot be
adequately tested in a system prototype
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
52
Throw-away prototyping
What
• Used to reduce requirements risk
• The prototype is developed from an initial
specification, delivered for experiment then
discarded
• The throw-away prototype should NOT be
considered as a final system
– Some system characteristics may have been left
out
– There is no specification for long-term maintenance
– The system will be poorly structured and difficult to
maintain
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
53
Prototype delivery
Why not
• Developers may be pressured to deliver a
throw-away prototype as a final system
• This is not recommended
– It may be impossible to tune the prototype
to meet non-functional requirements
– The prototype is inevitably undocumented
– The system structure will be degraded
through changes made during development
– Normal organisational quality standards
may not have been applied
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
54
Rapid prototyping techniques
What
• Various techniques may be used for rapid
development
– Dynamic high-level language development
– Database programming
– Component and application assembly
• These are not exclusive techniques - they are
often used together
• Visual programming is an inherent part of most
prototype development systems
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
55
Component and application assembly
What
• Prototypes can be created quickly from a set of
reusable components plus some mechanism to
‘glue’ these component together
• The composition mechanism must include
control facilities and a mechanism for
component communication
• The system specification must take into account
the availability and functionality of existing
components
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
56
Visual programming
What
• Scripting languages such as Visual Basic
support visual programming where the
prototype is developed by creating a user
interface from standard items and associating
components with these items
• A large library of components exists to support
this type of development
• These may be tailored to suit the specific
application requirements
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
57
Visual programming with reuse
Hypertext
display component
Date component
File
Edit
Views
12th January 2000
Range checking
script
What
Layout
Options
Help
General
Index
3.876
User prompt
component +
script
Draw canvas
component
Tree display
component
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
58
Problems with visual development
What
• Difficult to coordinate team-based development
• No explicit system architecture
• Complex dependencies between parts of the
program can cause maintainability problems
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
59
User interface prototyping
What
• It is impossible to pre-specify the look and feel of a
user interface in an effective way. Prototyping is
essential
• UI development consumes an increasing part of
overall system development costs
• User interface generators may be used to ‘draw’
the interface and simulate its functionality with
components associated with interface entities
• Web interfaces may be prototyped using a web
site editor
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
60
‫راهنماي مدرس ( اسليدهاي ‪)67-62‬‬
‫• ‪ Acceptance Test‬به عنوان يکي از تکنيکهاي ارزيابي در اين قسمت‬
‫تشريح ميگيردد‪ .‬حدود انجام اين تست مشخص مي شود و در نهايت‬
‫‪ Alpha Testing‬و ‪ Beta Testing‬براي تست نرم افزار معرفي مي‬
‫شوند‪.‬‬
‫• سپس اعتبارسنجي مدلها بررس ي شده و از طريق آن کيفيت مدلهاي تحليلي‬
‫بررس ي شده و موارد استفاده از اعتبارسنج مدلها بيان مي شود‪.‬‬
‫‪61‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Requirements validation techniques
•
•
•
•
What
Requirements reviews
Prototyping
Acceptance tests
Model Validation and Automated consistency
analysis
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
62
Acceptance Test
• Enable the customer to validate all
requirements
• Conducted by end user
• Can range from informal “test drive” to a
planned and systematically executed
series of tests
• If software is developed as a product to be
used by many customers a process called
alpha and beta testing is used.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
63
Alpha Testing
• Conducted at the developer’s site by a
customer
• Software is used in a natural setting with
the developer “looking over the shoulder”
of the user and recording errors and usage
problems.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
64
Beta Testing
• Conducted at one or more customer sites by the
end-user of the software.
• The developer is generally not present.
• Live application of the software in an
environment that can not be controlled by the
developer.
• Customer records all problems that are
encountered and reports them to the developer.
• Developer modifies software and then prepare
for release of the software product.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
65
Requirements validation techniques
•
•
•
•
What
Requirements reviews
Prototyping
Acceptance tests
Model Validation and Automated consistency
analysis
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
66
Model Validation
What
• Validating the quality of analysis models
• Is used to check the consistency of a structured
requirements description
• E.g. Static analysis to verify that communication
paths exist between objects that in stakeholder
domain exchange data.
• If formal specification is used, using formal
reasoning to prove properties of the
requirements specification (e.g. completeness)
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
67
‫پاسخ به پرسشها‬
‫‪.1‬اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟‬
‫‪.2‬چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟‬
‫‪.3‬تکنيکهاي اعتبارسنجي نيازها چيست؟‬
‫‪.4‬چه افرادي در جلسات بازنگري شرکت مي کنند؟‬
‫‪.5‬نقش نمونه سازي در اعتبارسنجي نيازها چيست؟‬
‫‪ .6‬نکات حائز اهميت در بازنگري نيازها چيست؟‬
‫‪68‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
What is V&V?
What
• Purpose of V&V is to deliver a product that works
properly and performs to customer expectations.
• Verification is the process of confirming deliverable
hardware and software are in compliance with the
functional, performance, and design
requirements.(Have we built the system right?)
• Validation is the process of providing evidence that a
systems meets the needs of the User.(Have we built
the right system?)
What we are trying to do is to establish confidence in the
system, support equipment, test equipment, and people.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
69
‫پاسخ به پرسشها‬
‫‪.1‬اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟‬
‫‪.2‬چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟‬
‫‪.3‬تکنيکهاي اعتبارسنجي نيازها چيست؟‬
‫‪.4‬چه افرادي در جلسات بازنگري شرکت مي کنند؟‬
‫‪.5‬نقش نمونه سازي در اعتبارسنجي نيازها چيست؟‬
‫‪ .6‬نکات حائز اهميت در بازنگري نيازها چيست؟‬
‫‪70‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Requirements checking
What
• Validity. Does the system provide the functions
which best support the customer’s needs?
• Consistency. Are there any requirements
conflicts?
• Completeness. Are all functions required by the
customer included?
• Realism. Can the requirements be implemented
given available budget and technology
• Verifiability. Can the requirements be checked?
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
71
‫پاسخ به پرسشها‬
‫‪.1‬اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟‬
‫‪.2‬چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟‬
‫‪.3‬تکنيکهاي اعتبارسنجي نيازها چيست؟‬
‫‪.4‬چه افرادي در جلسات بازنگري شرکت مي کنند؟‬
‫‪.5‬نقش نمونه سازي در اعتبارسنجي نيازها چيست؟‬
‫‪ .6‬نکات حائز اهميت در بازنگري نيازها چيست؟‬
‫‪72‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Requirements validation techniques
•
•
•
•
What
Requirements reviews
Prototyping
Acceptance tests
Model Validation and Automated consistency
analysis
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
73
‫پاسخ به پرسشها‬
‫‪.1‬اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟‬
‫‪.2‬چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟‬
‫‪.3‬تکنيکهاي اعتبارسنجي نيازها چيست؟‬
‫‪.4‬چه افرادي در جلسات بازنگري شرکت مي کنند؟‬
‫‪.5‬نقش نمونه سازي در اعتبارسنجي نيازها چيست؟‬
‫‪ .6‬نکات حائز اهميت در بازنگري نيازها چيست؟‬
‫‪74‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Roles in Review Meetings
Who
• a person has essential knowledge of the business or
technology domain and detailed knowledge of the
applied facilitation and modeling techniques:
– Requirements Reviewer
– Requirements Specifier
– System Analyst
• possibly at milestones such as the beginning or end of a
Phase:
–
–
–
–
Stakeholders - customers and end-users (Where possible)
Change Control Manager (Where reviewing Change Requests)
Test Designer (Optional)
Software Architect (Optional, usually in Inception and
Elaboration)
– Project Manager (Optional, usually at Phase Start)
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
75
‫پاسخ به پرسشها‬
‫‪.1‬اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟‬
‫‪.2‬چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟‬
‫‪.3‬تکنيکهاي اعتبارسنجي نيازها چيست؟‬
‫‪.4‬چه افرادي در جلسات بازنگري شرکت مي کنند؟‬
‫‪.5‬نقش نمونه سازي در اعتبارسنجي نيازها چيست؟‬
‫‪ .6‬نکات حائز اهميت در بازنگري نيازها چيست؟‬
‫‪76‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
Uses of system prototypes
What
• The principal use is to help customers and
developers understand the requirements for the
system
– Requirements elicitation. Users can experiment
with a prototype to see how the system supports
their work
– Requirements validation. The prototype can reveal
errors and omissions in the requirements
• Prototyping can be considered as a risk
reduction activity which reduces requirements
risks
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
77
‫پاسخ به پرسشها‬
‫‪.1‬اعتبارسنجي به چه معني است و با چه هدفي انجام مي شود؟‬
‫‪.2‬چه ويژگيهايي از نيازها در مرحله اعتبارسنجي ارزيابي مي شوند؟‬
‫‪.3‬تکنيکهاي اعتبارسنجي نيازها چيست؟‬
‫‪.4‬چه افرادي در جلسات بازنگري شرکت مي کنند؟‬
‫‪.5‬نقش نمونه سازي در اعتبارسنجي نيازها چيست؟‬
‫‪ .6‬نکات حائز اهميت در بازنگري نيازها چيست؟‬
‫‪78‬‬
‫‪Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory‬‬
General Guidelines for Review
What
• Good communications between developers,
customers and users can resolve problems at an
early stage
• Always conduct reviews in a meeting format,
although the meeting participants might prepare
some reviews on their own.
• Continuously check what is produced to make sure
the product quality is as high as possible.
Checkpoints are provided for this purpose; refer to
the checkpoints for each analysis activity.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory
79