1. 1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 3 - Software Systems and Requirements Analysis Dr Richard Clayton & Dr Marian Gheorghe Module (1 st part) homepage http://www.dcs.shef.ac.uk/~marian

2. 2COM6030 Systems Analysis and Design © University of Sheffield 2005 Outline  Overview of software systems  Problems with software systems  Requirements analysis  User requirements  System requirements  Software design specification Reading: Sommerville chapter 5; Bennett chapter 2

3. 3COM6030 Systems Analysis and Design © University of Sheffield 2005 Systems Environment Boundary Feed forward Feed back Control Sub-system System operation Interface input output

4. 4COM6030 Systems Analysis and Design © University of Sheffield 2005 First part of the course  Exist in an environment, and are separated from the environment by a boundary.  Have inputs from the environment and outputs to the environment.  May have sub-systems.  Have interfaces that allow communication with another system.  Often have a control mechanism, relying on feedback (or feed forward) information about the system’s operation or environment that is passed to the control system.  Complex systems consist of a large number of mutually interacting and interwoven parts.  Systems have some properties that are not directly dependent on the properties of its parts. These are called emergent, integrative or synergistic properties. Systems

5. 5COM6030 Systems Analysis and Design © University of Sheffield 2005 Computer based systems  A computer based system can be defined as a set of elements that are organised in a purposeful way to accomplish some method, procedure, or control, by processing information.  Elements of computer based systems transform information.

6. 6COM6030 Systems Analysis and Design © University of Sheffield 2005 What is a good software Good software is  Scalable  Secure  Robust  Maintainable  Correct  Cost-effective  Elegant  Easy to use Bad software is  Not extensible  Insecure  Dangerous  Impenetrable  Incorrect  Over budget  Clunky  Hated by users

7. 7COM6030 Systems Analysis and Design © University of Sheffield 2005 Problems with large software systems Many large software projects  Are delivered late  Do not work properly  Are over budget  Do not meet customer’s requirement Some projects are not delivered at all. Bill for failed software projects in the US in 1995 was up to $81 billion. Many of these failures can be attributed to the management of the software development process.

8. 8COM6030 Systems Analysis and Design © University of Sheffield 2005 Difficulties with requirements analysis If the requirements analysis is wrong, then the developer may have to  Modify software specification  Adapt software design  Repair software implementation  Generate new tests and apply them  Update documentation  Recall products already sold Requirements analysis is one of the most critical parts of software development, and is also one of the hardest to get right. This is the case regardless of development methodology. Fixing a requirements error may cost 100 x as much as an implementation error! Disaster! Costly and time consuming

9. 9COM6030 Systems Analysis and Design © University of Sheffield 2005 Communication issues Client and developer may  Use the same word to mean different things – e.g. “variable”.  Make different assumptions about the system – e.g. what is meant by “appropriate”, “its obvious!”. Developer Detailed knowledge of software development. May have experience of similar systems. Client/User Understanding problem domain. Little knowledge understanding of Software systems. How can we maximise this overlap

10. 10COM6030 Systems Analysis and Design © University of Sheffield 2005 Requirements analysis The purpose of requirements analysis is to establish what the system is intended to do, NOT how it is to be done.  Requires a clear understanding of overall business objectives, and the role of individual system users.  This is not easy because  The client may not have a clear idea of requirements.  Requirements may change.  Requirements may be initially written in an abstract way to allow several developers to bid for a contract.  Developer and client may not communicate effectively.  Furthermore “requirement” can be used inconsistently and this leads to confusion. It may describe either a high level abstract description of a system, or a detailed and formal definition of system function.  “Measure twice, and cut once.”

11. 11COM6030 Systems Analysis and Design © University of Sheffield 2005 Context  Understanding both overall business context (high level - abstract) and needs of individual users (low level - detailed) is critical.  Any current system will in part meet business needs, and users will usually be comfortable with it.  Understanding operation of current system is important.  Will new system actually bring any benefit?  When should a legacy system be abandoned?  Requirements should focus on future as well as current operations.  Three overall types of requirements  Functional requirements – what will the system do?  Non-functional requirements – How well will the system deliver functional requirements?  Usability requirements – how easy is the system to use?

12. 12COM6030 Systems Analysis and Design © University of Sheffield 2005 Functional requirements  Description of the processing that the system should do  Input and output relationships.  Specify behaviour for all possible inputs – including incorrect ones.  Consider all aspects of the user interface.  Details of the data that must be produced by the system.  Description of various functions of the system  Should be both complete and consistent, and expressed in a precise way.  Sometimes difficult to avoid or resolve logical inconsistencies, especially in large systems.  May be expressed as essential or desirable requirements.

13. 13COM6030 Systems Analysis and Design © University of Sheffield 2005 Non-functional requirements  Aspects of the system that are concerned with how well the system provides the functional requirements.  Somerville classifies these as  Product requirements – performance requirements, reliability requirements, portability. May be constrained by hardware on which the system will run.  Organisational requirements – conformance to policies and procedures within business organisation.  External requirements – legislative requirements, ethical requirements, and how the system interacts with other systems.  Also consider some implementation issues  Can the system be implemented within a realistic timescale?  Can it be tested satisfactorily?  Can it be maintained in the future?

14. 14COM6030 Systems Analysis and Design © University of Sheffield 2005 Usability requirements  Aim to make the system a pleasure to use  Need to take into account  Characteristics of users who will use the system.  The tasks that users undertake - is the sequence logical and intuitive?  Situational factors – how will the system respond to incorrect data entry?  Acceptance criteria – how do we know if a system is a success?

15. 15COM6030 Systems Analysis and Design © University of Sheffield 2005 Different types of requirements See Somerville chapter 5  User requirements – statements in natural language.  Important for client and developer management who do not need to know technical details of the system, but who need a correct overview.  Also vital for communicating with end-users.  Systems requirements – details of the system services and constraints.  Target at senior technical staff and project managers who need to know some technical detail so that they can make judgements.  May serve as a contract between client and developer.  Design specification. Adds detail to systems requirements, to give abstract description of the software design.  Implementation oriented document – engineers dev. the system

16. 16COM6030 Systems Analysis and Design © University of Sheffield 2005 Example – ATM withdrawal Extract from detailed requirements specification developed by Professor Russell Bjork, and used with permission. For full details see http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/ “The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned. Which of these requirements are functional, non-functional, and usability?

17. 17COM6030 Systems Analysis and Design © University of Sheffield 2005 Example – ATM withdrawal Extract from detailed requirements specification developed by Professor Russell Bjork, and used with permission. For full details see http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/ “The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned. Which of these requirements are functional, non-functional, and usability?

18. 18COM6030 Systems Analysis and Design © University of Sheffield 2005 Example – ATM withdrawal Extract from detailed requirements specification developed by Professor Russell Bjork, and used with permission. For full details see http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/ “The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned. Which of these requirements are functional, non-functional, and usability?

19. 19COM6030 Systems Analysis and Design © University of Sheffield 2005 Example – ATM withdrawal Extract from detailed requirements specification developed by Professor Russell Bjork, and used with permission. For full details see http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample/ “The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link. The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned. Which of these requirements are functional, non-functional, and usability?

20. 20COM6030 Systems Analysis and Design © University of Sheffield 2005 Summary  Large scale software systems are notoriously expensive, and many fail altogether.  Requirements analysis is a critical component of successful software systems.  Requirements capture and analysis is difficult.  There are no correct answers.