1 Requirements Requirements Analysis and Analysis and Design Design Engineering Engineering Southern Methodist University CSE 7313
Dec 26, 2015
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
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
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)