1

RequirementsRequirementsAnalysis andAnalysis and

DesignDesignEngineeringEngineering

Southern Methodist University

CSE 7313

2

Categorizing requirements Categorizing requirements into useful typesinto useful types

Functional; things the product must do Non-functional; properties or qualities that

the product must have Constraints; global requirements

Defined before beginning the work gathering the requirements

Users are a constraint! Product must run on a Unix machine

Project Issues

3

Non-functional Non-functional requirementsrequirements

Look and feel requirements Usability requirements Performance requirements Operational requirements Maintainability and portability

requirements Security requirements Cultural and political requirements Legal requirements

4

Look and feelLook and feel

Highly readable Apparently simple to use Approachable so people will use it Authoritative so users will trust it Conforming to the clients other products Colorful and attractive to children Unobtrusive so people are not aware of it Innovative and appearing state of the art Professional and executive looking

5

Usability requirementsUsability requirements

Rate of acceptance by users Productivity gained from the product Errors rates (or reduction thereof) Being used by people who do not speak

the language where product is used Accessibility to handicapped people Being used by people with no prior

experience with computers

6

Performance requriements Performance requriements

Speed to complete a task Accuracy of the results Safety to the operator Volumes to be held by the product Ranges of allowable values Throughput (rate of transactions) Efficiency of resource usage Reliability (MTBF)

7

Operational requirementsOperational requirements

Operating environment Condition of the users (dark, hurry, etc) Partner or collaborating systems Portable products

8

Maintainability requirementsMaintainability requirements

Organization Environment Laws that apply to the product Business rules

9

Security requirementsSecurity requirements

ConfidentialityData stored by product is protected

AvailabilityAccessible to authorized users

IntegrityProducts data are the same as the

source or authority of the data

10

Constraints Constraints

Purpose of the product Client, customer, other stakeholders Users of the product Requirements constraints Naming conventions and definitions Relevant facts Assumptions

11

Project issuesProject issues

Open issues Off the shelf solutions (COTS) New problems Tasks Cutover Risks Costs User documentation Waiting room

12

Risk managementRisk management

13

Risks that can do damageRisks that can do damage

Inaccurate metrics Inadequate measurement Excessive schedule pressure Management malpractice Inaccurate cost estimates Silver bullet syndrome Creeping user requriements Low quality

14

Risks to the requirements Risks to the requirements processprocess

Absence of a clear and measurable purpose for the project

Lack of client involvement Lack of stakeholder involvement Little or no agreement on requirements Requirements creep Gold plating No measurements put on requirements

(customer satisfaction/dissatisfaction)

15

Risks to the requirements Risks to the requirements processprocess

Rapidly changing requirements Inadequate change control New or unknown business area with

certain needs

16

The role of adjacent The role of adjacent systemssystems

17

Types of adjacent systemsTypes of adjacent systems

Active adjacent systems Autonomous adjacent systems Cooperative adjacent systems

18

Active adjacent systemsActive adjacent systems

These systems behave dynamically Interact or participate in the work Usually humans

Initiate events with some objective in mind

Interact with the product by exchanging data and other signalsBank customer interacting with a bank

19

Active adjacent systemsActive adjacent systems

You can predict its behavior within reason You can expect it to respond to signals

from your workWill comply if perceived benefit

Will respond in a suitably short period of time

Is actually part of the work

20

Autonomous adjacent Autonomous adjacent systemssystems

Some external body that does not directly interact with the systemGovernment department

Acts independently of the work being studied but has connections to it

Communicate through one day data flowsCredit card company sending you a monthly

statement – you act as autonomous adjacent system

You act as a sink of information (act when ready)

21

Autonomous adjacent Autonomous adjacent systemssystems

Autonomous adjacent systems use one way communication because of technology or preference

These systems do not involve themselves in the response to the business events that it triggers

Make sure that an autonomous adjacent system should not really be an active adjacent system

22

Cooperative adjacent Cooperative adjacent systemssystems

Cooperative adjacent systems can be relied on to behave predictably when called upon

Cooperate with the product to bring about some desired outcome

Usually done by means of some simple request-response dialogAnother product containing a DB used

by your workAn OS

23

Cooperative adjacent Cooperative adjacent systemssystems

We can access a cooperative adjacent system, store data in it, request information from it

Behavior is consistent and predictable Can consider a cooperative adjacent

system to be part of the response to the business event (part of the use case)Processing of the use case does not stop

when it reaches the adjacent system (even though it is not part of the product)

24

Role of adjacent systemsRole of adjacent systems

The part played by the adjacent system is dependent on its capabilities and willingness to participate

Must understand/study the following;Ability to respond in a timely mannerWillingness to respondTechnological compatibility with the

work (effectiveness depends on effective comm link that does not require slow transactions)

25

Role of adjacent systemsRole of adjacent systems

Policy with regard to respondingProximity to the work (affects the

medium of communication and the time taken)

Ownership (different ownership may be less inclined to participate)

Interests (is it in the interest to participate or not)