Overview of Requirements Engineering - PowerPoint PPT Presentation

Loading...

PPT – Overview of Requirements Engineering PowerPoint presentation | free to download - id: 77fb96-MmRhN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Overview of Requirements Engineering

Description:

Overview of Requirements Engineering Section One Version: 1.0 Mehr 1383 – PowerPoint PPT presentation

Number of Views:137
Avg rating:3.0/5.0
Slides: 69
Provided by: Shirazi
Learn more at: http://ceit.aut.ac.ir
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Overview of Requirements Engineering


1
Overview of Requirements Engineering
  • Section One
  • Version 1.0
  • Mehr 1383

2
???? ??????
  1. ????? ??? ?????? ?????? ??????? ?????? ?????
    ????? ???? ????? ??????? ? ????? ??????? ???????
    ?????
  2. ????? ? ???????? ????? ?????? ??????? ?? ?????
  3. ?????? ????? ? ???????? ??? ???? ?????? ??
    ??????????? ???? ? ????
  4. ???? ???? ????? ?????????? ? ?????? ????? ???? ?
    ???????? ???? ???? ??? ???? ?? ?? ?? ??????
  5. ???? ????? ??????????

3
?????? ??????
  • ??????? ?? ????? ?????
  • ?????? ? ?????? ?????? ????? ?? ?????? ????
  • ?????? ? ?????? ??????? ????? ?? ?? ????? ???? ??
    ??????? ????
  • ????? ?????? ?????? ?? ????? ?? ?? ?? ????? ?????
    ??? ??? ?????? ????? ?? ????
  • ???????? ?????? ???? ????? ?????? ?????
  • ?? ????? ?? ?????? ?????? ? ????? ???? ???????
    ????? ?????? ?? ???????

4
??????? ???? (????????? 5-13)
  • ?? ??? ???? ?? ????? ??? ?????? ?????? ??????? ??
    ???. ?? ??? ????? ??
  • ?? ?? ??????(????????? ????? 5 ? 6) ??? ??????
    ????? ?? ?????? ?? ?????? ?????? ???? ??? ?
    ?????? ?? ?????? ??? (?????? ????? 7) ?????? ????
    ???? ?? ????? ??? ???.
  • ?? ?? ?????? ???? ? ??? ?????? ?????? ??????
    ????? ??? ? ????? ?? ??? ?? ???.
  • ?? ?? ?????? ???? ????? ??????? ?? ? ????? ?????
    ??? ???? ??? ??? ? ??????
  • ?? ?????? ?????? ????? ?????? ?????? ?????? ?????
    ?? ???.

5
What is requirement engineering?
What
  • RUP Definition
  • A systematic approach to
  • eliciting, organizing, and documenting the
    requirements of the system, and
  • establishing and maintaining agreement between
    the customer and the project team on the changing
    requirements of the system.

6
What is requirement engineering?
What
  • Sumerville Definition
  • Appropriate mechanism for understanding what the
    customer wants, analyzing needs, negotiating a
    reasonable solution, validating the specification
    and managing changes in requirements.

7
Requirement Engineering Our definition
What
  • A systematic and disciplined approach to
    eliciting, organizing, documenting, analyzing,
    validating and managing changes in the
    requirements of the system.

8
RE as a Software Engineering Task
Where
  • Requirements Engineering (Analysis) is a software
    engineering task that bridge the gap between
    system level requirements engineering and
    software design. Pressman

9
Why Requirement Engineering?
Why
  • To capture the specific requirements that must be
    achieved to build high-quality software.
  • If we dont engineer the requirements
  • In most systems, Its highly likely that youll
    build a very elegant software solution that
    solves a wrong problem.
  • The result is
  • Wasted time and money
  • Personal frustration
  • Unhappy Users

10
Who does requirement engineering?
Who
  • Depending on project complexity a team of
  • Software engineer
  • System analyst
  • Business analyst
  • Requirements specifier
  • Requirements Reviewer
  • Other Stakeholders

11
Requirements Engineering Process
How
  • The processes used for Requirement Engineering
    vary widely depending on
  • The application domain
  • The people involved
  • The organisation developing the requirements.

12
Requirements Engineering Process
How
  • Generic activities common to all RE processes
  • Requirements Elicitation
  • Requirements Analysis
  • Requirements Validation
  • Requirement Specification
  • Requirements Change Management.

13
What is the RE artifact?
What
  • Software Requirements Specification An effective
    representation of the software must be produced
    as a consequence of requirement analysis.
  • Software requirements can be represented using a
    prototype, a specification document or even a
    symbolic model.

14
??????? ???? (????????? 15-26)
  • ?? ??? ???? ?? ????? ??????? ???? ?????? ??? ?
    ???? ??????? ?? ???? ?? ???. ?? ??? ????? ??
  • ????? ?????? ????? ????? ???? ??????? ????? ?????
    ?? ???.
  • ??? ?????? ????? ???? ???? ??? ? ?? ?????? ??????
    ?? ????.
  • ?? ?? ?? ????? ? ???????? ????? ?????? ??????? ??
    ????? ???? ????? ???? ????? ? ??????
  • ?????? ????? ? ???????? ??? ???? ?????? ??
    ??????????? ???? ? ???? ???? ?? ????.

15
How do I ensure that Ive done it right?
How
  • Work products must be reviewed for
  • Clarity
  • Completeness
  • Consistency
  • By
  • Validation and Verification
  • with techniques and tools on defined methodology

16
What is a Requirement?
What
  • A property that must be exhibited by a system
    developed or adapted to solve a particular
    problem SWEBOK.
  • A requirement is defined as "a condition or
    capability to which a system must conform" RUP.

17
What is a Requirement?
What
  • A statement about the proposed system that all
    stakeholders agree must be made true in order for
    the Users problem to be adequately solved
    Lethbridge.
  • Key points
  • Short and concise piece of information
  • Says something about the system
  • All the stakeholders have agreed that it is valid
  • It helps solve the Users problem

18
What is a Requirement?
What
  • It may range from a high-level abstract statement
    of a service or of a system constraint to a
    detailed mathematical functional specification.
    Ian Summerville
  • This is inevitable as requirements may serve a
    dual function
  • May be the basis for a bid for a contract -
    therefore must be open to interpretation
  • May be the basis for the contract itself -
    therefore must be defined in detail
  • Both these statements may be called requirements.

19
What is a Requirement?
What
  • A contract for a large software development
    project
  • define it needs in a sufficiently abstract way
  • A solution is not pre-defined.
  • several contractors can bid for the contract
  • Once a contract has been awarded,
  • the contractor must write a system definition for
    the client
  • in more detail
  • the client understands and validates it
  • Both of these documents may be called the
    requirements document for the system Davis.

20
Overview of Definitions
What
What Summerville Lethbridge Davis RUP SWEBOK
Property
Condition
Statement
Service
System constraint
Contract
21
Overview of Definitions
What
Goal Summerville Lethbridge Davis RUP SWEBOK
Solve a problem
Conform the condition
For agreement of stakeholders
How
Short and consistence
Different levels of abstraction
22
An Ambiguous Expectation
Why
23
Results of Incorrect Requirements
Why
  • The system may cost more than projected.
  • The system may be delivered later than promised.
  • The system may not meet the users expectations
    and that dissatisfaction may cause them not to
    use it.
  • Once in production, the costs of maintaining and
    enhancing the system may be excessively high.
  • The system may be unreliable and prone to errors
    and downtime.
  • The reputation of the IT staff on the team is
    influenced because any failure, regardless of who
    is at fault, will be perceived as a mistake by
    the team.

24
Relative Cost to Fix an Error
Why
25
Requirements and Process Models
What
  • Some process models attempt to fully define and
    stabilize the requirements in the first phase of
    a project. (Waterfall, RAD,)
  • In most of the current process models there is no
    need to have a fixed and complete definition of
    requirements at the early stages of development.
    They let the requirements to change and manage
    these changes during development. (RUP, Agile
    development, XP,..)

26
Challenged software projects
Why
27
??????? ???? (????????? 28-48)
  • ?? ??? ???? ?????? ????? ???? ??? ? ???? ???????
    ???? ????? ???? ????? ? ???????? ??? ???? ???
    ????? ?? ???. ?? ??? ????? ??
  • ?? ?????? 28 ?????? ?? ?? ???? ??? ????? ?? ????.
  • ?? ?? ?????? ???? ???? ??? ????? ?? ???.
  • ??? ???? ??? ???? ????? ???? ????? ? ???? ????
    ???
  • ? ?? ?? ?? ???????????? ???? ???? ????? ?????
    ?????? ????? ?? ????.
  • ??? ???????? ???? ???? ??? ???? ?????? ??? ?????
    ???? ?? ?????.

28
Types of Requirements
What
  • Functional requirements
  • Statements of services the system should provide,
    how the system should react to particular inputs
    and how the system should behave in particular
    situations.
  • Non-functional requirements
  • constraints on the services or functions offered
    by the system such as timing constraints,
    constraints on the development process,
    standards, etc.

29
Functional Requirements
What
  • Functional requirements specify actions that a
    system must be able to perform, without taking
    physical constraints into consideration.

30
Functional Requirements (cont.)
What
  • What inputs the system should accept
  • What outputs the system should produce
  • What data the system should store that other
    systems might use
  • What computations the system should perform
  • The timing and synchronization of the above

31
Functional requirements static or dynamic
What
Dynamic Describes the behavior of a system or
system component in terms of the results produced
by executing the system under specified
circumstances. Static Describes the functions
performed by each entity and the way each
interacts with other entities and the
environment.
32
Non-functional requirements
What
  • Sometimes known as constraints or quality
    requirements SWEBOK
  • Such as reliability, response time and storage
    requirements. Constraints are I/O device
    capability, system representations, etc.
  • Process requirements may also be specified
    mandating a particular CASE system, programming
    language or development method.
  • Non-functional requirements may be more critical
    than functional requirements. If these are not
    met, the system is useless.

33
1 Non-functional classifications
What
  • Product requirements
  • Requirements which specify that the delivered
    product must behave in a particular way e.g.
    execution speed, reliability, etc.
  • Organisational requirements
  • Requirements which are a consequence of
    organisational policies and procedures e.g.
    process standards used, implementation
    requirements, etc.
  • External requirements
  • Requirements which arise from factors which are
    external to the system and its development
    process e.g. interoperability requirements,
    legislative requirements, etc.

34
1Non-functional requirement types
What
35
2 Non-functional Requirements Classification
What
  • One way of categorizing requirements is
    described as the FURPS model,
  • with subcategories as shown below
  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability
  • The "" in FURPS reminds you to include
    requirements such as
  • design constraints
  • implementation requirements
  • interface requirements
  • physical requirements.

36
3 ISO/IEC 9126 Quality Model (1/2)
What
  • Validate the completeness of a requirements
    definition
  • Identify software requirements
  • Identify software design objectives
  • Identify software testing objectives
  • Identify quality assurance criteria
  • Identify acceptance criteria for a completed
    software product.

37
3ISO/IEC 9126 Quality Model (2/2)
What
  • A framework for software product quality
    definition in the customer-supplier process
  • Support for review, verification and validation,
    and a framework for quantitative quality
    evaluation, in the support process
  • Support for setting organisational quality goals
    in the management process.
  • A framework for software product quality
    requirements definition in the primary lifecycle
    process

38
3Software Quality Attributes ISO/IEC 9126
What
39
3Software Quality Attributes ISO/IEC 9126
What
40
Functionality (1/3)
What
  • Suitability
  • An unsatisfying function or operation may
    be
  • a) Functions and operations that do not perform
    as specified in user manuals or requirement
    specification.
  • b) Functions and operations that do not provide a
    reasonable and acceptable outcome to achieve the
    intended specific objective of the user task.

41
Functionality (2/3)
What
  • Accuracy
  • Incorrect or imprecise result caused by
    inadequate data
  • Inconsistency between actual operation procedures
    and described ones in the operation manual
  • Differences between the actual and reasonable
    expected results of tasks performed during
    operation.

42
Functionality (3/3)
What
  • Interoperability
  • Security
  • a) Failing to prevent leak of secure output
    information or data
  • b) Failing to prevent loss of important data
  • c) Failing to defend against illegal access or
    illegal operation.

43
Reliability
What
  • Maturity (software freedom of failures)
  • Fault tolerance (software capability of
    maintaining a specified performance level in
    cases of operation faults)
  • Recoverability (system being able to re-establish
    its adequate level of performance)
  • Reliability compliance

44
Usability (1/2)
What
  • Understandability
  • Whether new users can understand
  • Whether the software is suitable
  • How it can be used for particular tasks.
  • Learnability
  • Attractiveness
  • Usability compliance

45
Usability (2/2)
What
  • Operability
  • suitability of the software for the task
  • self-descriptiveness of the software
  • controllability of the software
  • conformity of the software with user expectations
  • error tolerance of the software
  • suitability of the software for individualization

46
Efficiency
What
  • Time behaviour
  • Resource utilization
  • Efficiency compliance

47
Maintainability
What
  • Analysability effort or spent of resources when
    trying to diagnose deficiencies or causes of
    failures, or for identifying parts to be
    modified.
  • Changeability
  • Stability
  • Testability
  • Maintainability compliance

48
Portability
What
  • Adaptability
  • Installability
  • Co-existence
  • Replaceability
  • Portability compliance

49
??????? ???? (????????? 49-52)
  • ?? ??? ???? ????? ??? ????? ?? ????
  • ????? ???? ????? ???????? ????? ?? ???.
  • ?? ?? ?? ?? ????? ????? ????? ???
  • ? ?????? ?????? ?? ?? ?????? ?????? ? ????? ????
    ??????? ????? ?????? ?? ?????? ????? ?? ????.

50
System Requirements vs. User Requirements
What
  • User requirements
  • They denote the requirements of the people who
    will be the system Users or end-users.
  • System requirements
  • Requirements of other stakeholders (such as
    regulatory authorities) and requirements that do
    not have identifiable human source. SWBOK

51
System stakeholders
Why
  • Users
  • the people who will operate the system.
  • Customers
  • the people who commissioned the system or who
    represent the systems target market.
  • Regulators
  • System developers
  • these have legitimate interest in profiting from
    developing the system.
  • Devices or systems in the environment.

52
Requirements readers
53
???? ?? ??????
  • ??????? ?? ????? ?????
  • ?????? ? ?????? ?????? ????? ?? ?????? ????
  • ?????? ? ?????? ??????? ????? ?? ?? ????? ???? ??
    ??????? ????
  • ????? ?????? ?????? ?? ????? ?? ?? ?? ????? ?????
    ??? ??? ?????? ????? ?? ????
  • ???????? ?????? ???? ????? ?????? ?????
  • ?? ????? ?? ?????? ?????? ? ????? ???? ???????
    ????? ?????? ?? ???????

54
Overview of Definitions
What Summerville Lethbridge Davis RUP SWEBOK
Property
Condition
Statement
Service
System constraint
55
Overview of Definitions
Goal Summerville Lethbridge Davis RUP SWEBOK
Solve a problem
Conform the condition
For agreement of stakeholders
How
Short and consistence
Different levels of abstraction
56
???? ?? ??????
  • ??????? ?? ????? ?????
  • ?????? ? ?????? ?????? ????? ?? ?????? ????
  • ?????? ? ?????? ??????? ????? ?? ?? ????? ???? ??
    ??????? ????
  • ????? ?????? ?????? ?? ????? ?? ?? ?? ????? ?????
    ??? ??? ?????? ????? ?? ????
  • ???????? ?????? ???? ????? ?????? ?????
  • ?? ????? ?? ?????? ?????? ? ????? ???? ???????
    ????? ?????? ?? ???????

57
Why it is important?
  • If we dont analysis the requirements
  • In most systems, Its highly likely that youll
    build a very elegant software solution that
    solves a wrong problem.
  • The result is
  • Wasted time and money
  • Personal frustration
  • Unhappy Users

58
???? ?? ??????
  • ??????? ?? ????? ?????
  • ?????? ? ?????? ?????? ????? ?? ?????? ????
  • ?????? ? ?????? ??????? ????? ?? ?? ????? ???? ??
    ??????? ????
  • ????? ?????? ?????? ?? ????? ?? ?? ?? ????? ?????
    ??? ??? ?????? ????? ?? ????
  • ???????? ?????? ???? ????? ?????? ?????
  • ?? ????? ?? ?????? ?????? ? ????? ???? ???????
    ????? ?????? ?? ???????

59
Results of Incorrect Requirements
  • The system may cost more than projected.
  • The system may be delivered later than promised.
  • The system may not meet the users expectations
    and that dissatisfaction may cause them not to
    use it.
  • Once in production, the costs of maintaining and
    enhancing the system may be excessively high.
  • The system may be unreliable and prone to errors
    and downtime.
  • The reputation of the IT staff on the team is
    influenced because any failure, regardless of who
    is at fault, will be perceived as a mistake by
    the team.

60
???? ?? ??????
  • ??????? ?? ????? ?????
  • ?????? ? ?????? ?????? ????? ?? ?????? ????
  • ?????? ? ?????? ??????? ????? ?? ?? ????? ???? ??
    ??????? ????
  • ????? ?????? ?????? ?? ????? ?? ?? ?? ????? ?????
    ??? ??? ?????? ????? ?? ????
  • ???????? ?????? ???? ????? ?????? ?????
  • ?? ????? ?? ?????? ?????? ? ????? ???? ???????
    ????? ?????? ?? ???????

61
Relative Cost to Fix an Error
62
???? ?? ??????
  • ??????? ?? ????? ?????
  • ?????? ? ?????? ?????? ????? ?? ?????? ????
  • ?????? ? ?????? ??????? ????? ?? ?? ????? ???? ??
    ??????? ????
  • ????? ?????? ?????? ?? ????? ?? ?? ?? ????? ?????
    ??? ??? ?????? ????? ?? ????
  • ???????? ?????? ???? ????? ?????? ?????
  • ?? ????? ?? ?????? ?????? ? ????? ???? ???????
    ????? ?????? ?? ???????

63
3 ISO/IEC 9126 Quality Model (1/2)
What
  • Validate the completeness of a requirements
    definition
  • Identify software requirements
  • Identify software design objectives
  • Identify software testing objectives
  • Identify quality assurance criteria
  • Identify acceptance criteria for a completed
    software product.

64
3ISO/IEC 9126 Quality Model (2/2)
What
  • A framework for software product quality
    definition in the customer-supplier process
  • Support for review, verification and validation,
    and a framework for quantitative quality
    evaluation, in the support process
  • Support for setting organisational quality goals
    in the management process.
  • A framework for software product quality
    requirements definition in the primary lifecycle
    process

65
3Software Quality Attributes ISO/IEC 9126
What
66
3Software Quality Attributes ISO/IEC 9126
What
67
???? ?? ??????
  • ??????? ?? ????? ?????
  • ?????? ? ?????? ?????? ????? ?? ?????? ????
  • ?????? ? ?????? ??????? ????? ?? ?? ????? ???? ??
    ??????? ????
  • ????? ?????? ?????? ?? ????? ?? ?? ?? ????? ?????
    ??? ??? ?????? ????? ?? ????
  • ???????? ?????? ???? ????? ?????? ?????
  • ?? ????? ?? ?????? ?????? ? ????? ???? ???????
    ????? ?????? ?? ???????

68
Requirements readers
About PowerShow.com