1 Requirements Analysis and Design Engineering Southern Methodist University CSE 7313

2 Categorizing requirements into 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 requirements  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 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 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  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 requirements  Operating environment  Condition of the users (dark, hurry, etc)  Partner or collaborating systems  Portable products

8 Maintainability requirements  Organization  Environment  Laws that apply to the product  Business rules

9 Security requirements  Confidentiality  Data stored by product is protected  Availability  Accessible to authorized users  Integrity  Products data are the same as the source or authority of the data

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

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

12 Risk management

13 Risks 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 process  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 process  Rapidly changing requirements  Inadequate change control  New or unknown business area with certain needs

16 The role of adjacent systems

17 Types of adjacent systems  Active adjacent systems  Autonomous adjacent systems  Cooperative adjacent systems

18 Active 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 signals  Bank customer interacting with a bank

19 Active adjacent systems  You can predict its behavior within reason  You can expect it to respond to signals from your work  Will comply if perceived benefit  Will respond in a suitably short period of time  Is actually part of the work

20 Autonomous adjacent systems  Some external body that does not directly interact with the system  Government department  Acts independently of the work being studied but has connections to it  Communicate through one day data flows  Credit 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 systems  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 systems  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 dialog  Another product containing a DB used by your work  An OS

23 Cooperative adjacent systems  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 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 manner  Willingness to respond  Technological compatibility with the work (effectiveness depends on effective comm link that does not require slow transactions)

25 Role of adjacent systems  Policy with regard to responding  Proximity 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)