Вы находитесь на странице: 1из 32

Requirements Analysis

1
Modeling

• the construction of abstract descriptions


that are amenable to interpretation

• the kind of analysis and reasoning it offers

• provides ease for analyzing requirements


Structural Approach
• Data flow diagrams

• ER diagram

• Functions

• ..

3
OORE
• Object-Oriented RE (OORE)
– Classes

– Objects

– States

– Generalization

– Inheritance
–…
4
SOA
• Service-Oriented Architecture
• Services - core artifacts
• Published and Discovered
– Producer centric

– Consumer centric

– Broker centric

5
Conceptual model of SOA

6
SOA…

7
SORE…
• Focuses
– identifying services and workflows,

– and modeling the application using identified


service and workflow specifications

– discovering either at design time (static SOA)


or at runtime (dynamic SOA).

– Dynamic SOA: rebinding, re-composition, and re-


architecting systems
8
SORE…

9
SORE…
• Service
– identification,
– classification
– categorization,
• subsystem analysis,

• component specification,

• Service allocation, and

• Service realization.
10
11
12
GORE
• Goals : artifacts
• A goal is a prescriptive statement of intent
that the system should satisfy through the
cooperation of its agents
• An agent is an active system component
playing a specific role in goal satisfaction
– Human agents
– Devices
– Existing SW components
– New SW components
13
GORE…
• Goal types /semantic/
• Behavioural goals
– Prescribe intended system behaviour
declaratively
• Soft goals
– Prescribe preferences among alternative
system behaviours
• Goal Categories /pragmatic/
• Functional goals
• Non-functional goals
14
Prioritizing
Requirements

15
Requirement Priorities
• the most urgent requirements in the first
release

• some would be performed very often and


others just occasionally or only by a few
people

• resource limitations
16
Requirement Priorities…
• Prioritization helps the project
manager
–resolve conflicts,
–plan for staged deliveries, and
–make the necessary trade-offs

17
Requirement Priorities…
• a way to deal with competing demands for
limited resources
• customer expectations are high and timelines
are short
• is critical for timeboxed or incremental
development with tight, immovable release
schedules
• importance and urgency
• customers must indicate which requirements
are needed initially and which can wait
18
Requirement Priorities…
• Establish priorities early in the project
• Achieving consensus among multiple customers
with diverse expectations is even harder
• Customers place a high priority on those
functions that provide the greatest business or
usability benefit
• The developer might also decide to implement
certain lower priority functions early on because
of their impact on the system's architecture

19
Requirement Priorities…
• If all requirements are top priority,
– your project has a high risk of not being fully
successful

• When you evaluate priorities,


– look at the connections and interrelationships
among different requirements and their alignment
with the project's business objectives

20
High, medium, and low approach
• subjective and imprecise
• stakeholders must agree on
• two dimensions: importance and urgency

• High priority requirements:


– important (the user needs the capability)
– urgent (the user needs it in the next release).

21
High…
• Medium priority requirements:
– important (the user needs the capability)
– but not urgent (they can wait for a later release).

• Low priority requirements:


– not important (the user can live without the
capability if necessary) and
– not urgent (the user can wait, perhaps forever).

22
High…

Important Not Important

Urgent High priority ??? (don’t do these)

Not urgent Medium priority Low priority

23
Specification

24
Requirements documentation
• Vision and Scope /business requirements/

• Use cases /user requirements/

• Functional and non-functional /SRS/


– purpose,
– structure, and
– contents
25
SRS template
1. Introduction
1.1Purpose
1.2 Document Conventions
1.3 Project Scope
1.4 References

26
SRS template…
2. Overall Description
2.1 Product Perspective

2.2 Business Rules

2.3 User Classes and Characteristics

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 Assumptions and Dependencies

27
SRS template…
3. System Features
3.x System Feature X
3.x.1 Description and Priority
3.x.2 Related Use cases
3.x.3 Functional Requirements
4. Data Requirements
4.1 Logical Data Model
4.2 Data Dictionary
4.3 Reports
4.4 Data Acquisition, integrity, retention, and disposal

28
SRS template…
5. External Interface Requirements
5.1 User Interfaces
5.2 Software Interfaces
5.3 Hardware Interfaces
5.4 Communications Interfaces
6. Quality Attributes
6.1 Usability
6.2 Performance
6.3 Security
6.4 Safety Requirements
6.x [others]
29
SRS template…
• 7. Internationalization and Localization
Requirements

• 8. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models /Context diagram, Use
cases, Class diagram, System Model

30
Read
Chapter 10 – Chapter 14

• CHAPTER 10 Documenting the requirements


• CHAPTER 11 Writing excellent requirements
• CHAPTER 12 A picture is worth 1024 words
• CHAPTER 13 Specifying data requirements
• CHAPTER 14 Beyond functionality
Q????
• Why should not expect all audiences read the
SRS in detail?
• Why is it important to use divide-and-conqure
approach in SRS for large projects?
• What kind of numbering is more appropriate
for labeling requirements?
• How do we specify data requirements?
• How do we prioritize quality attributes?

32

Вам также может понравиться