CSE Software Engineering: Analysis and Design, 2003Lecture 3B.1 Software Engineering: Analysis and Design - CSE3308 What is Analysis and Design? Monash University - School of Computer Science and Software Engineering CSE3308/DMS/2003/8

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.2 Lecture Outline u Defining Analysis and Design u Why do Analysis and Design? u Types of Analysis and Design u Requirements Engineering

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.3 Definitions u Many different definitions of the difference between analysis and design u In the past there was common agreement vWas viewed as follows: Essential Model Implementation Model Role of the AnalystRole of the Designer Description of the ProblemDescription of the Solution

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.4 Definitions (2) u Structured Analysis and Structured Design v different tools used to develop system v often different teams used to do analysis and design v clear distinction between tasks v leads to the “Analysis/Design Wall” analysisdesign

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.5 Definitions (3) u With newer development methods, the divide between analysis and design breaks down v the concept of seamlessness: » an essential model is very difficult to develop without reference to implementation issues v the increasing emphasis on requirements analysis u Some commentators see only v Requirements Analysis v High-level Design v Low-level Design u The debate rages on!

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.6 Definitions (4) u Systems Analysis v Process of » defining a problem » gathering the requirements » developing an analysis model representing those requirements v Describing the problem the system is meant to solve u Systems Design v Process by which the analysis model is transformed into a model which is capable of being implemented v Describing the solution to the problem

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.7 Why do analysis and design? u Add formality u Reduce errors u Improve communication between participants u Get the requirements right! u The cost of fixing analysis and design errors as one moves from the analysis phase to the maintenance phase can increase by a factor of 100 u Generate documentation

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.8 Cost of Analysis/Design Errors

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.9 Source of Errors

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.10 Types of Analysis/Design u Top-down Analysis and Design v Structured Analysis v SADT u Object-Oriented Analysis and Design v Object Modeling Technique (OMT) v Booch OOA&D v Unified Modeling Language (UML) v OPEN/Mentor (Australian based) Brian Henderson-Sellars and Object-Oriented Pty. Ltd. u Data-Driven Analysis and Design v Jackson System Design v Warnier-Orr Method

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.11 Requirements Engineering u Challenge facing system and software engineers vHow can we ensure that we have specified a system that: »Properly meets the customer’s needs »Satisfies the customer’s expectations u Requirements engineering provides mechanisms for: vUnderstanding what the customer wants vanalysing need vassessing feasibility vnegotiating a reasonable solution v specifying the solution vvalidating the specification vmanaging the transformation of the requirements into an operational system

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.12 Requirements Engineering u The requirements engineering process can be described in six steps: vRequirements elicitation vRequirements analysis and negotiation vRequirements specification vSystem modelling vRequirements validation vRequirements management u We will discuss some of these in more detail

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.13 Requirements Elicitation u It might seem that this should be simple: vAsk the customer, users, and others: »What the objectives for the system are »What is to be accomplished »How the system fits the into the needs of the business »How the system will be used on a day-to-day basis u In fact it is hard! vProblems of scope vProblems of understanding vProblems of volatility

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.14 Problems of Scope u The boundary of the system may be ill- defined vWho is going to interact with the system? vWhat other systems are involved? vExactly what functionality is the responsibility of the system »e.g. should a rostering system produce a telephone directory? u The customer/user may specify unnecessary technical detail that may confuse overall system objectives ve.g. specifying OS, language, hardware, etc. for no particularly good reason

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.15 Problems of Understanding u Customers/users may: vNot be completely sure of what is needed, e.g.: »“See what you can do to help us” (Marketing director of textile business) »“Try to improve the project” (Director of British Aircraft Corporation, with reference to the Concorde project) vHave a poor understanding of the capabilities and limitations of their computing equipment vNot have a full understanding of the problem domain vHave trouble communicating needs to system engineer vOmit information believed to be “obvious” vSpecify requirements that conflict with needs of others vSpecify requirements that are ambiguous or untestable

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.16 Problems of Volatility u Requirements change over time u Change is inevitable in most systems, due to factors such as: vChanges in customer organization, e.g. »new divisions, new products vChanges in scale, e.g. »Number of transactions per day »Number of users »Increased connection bandwidth vExternal changes »Changes in law (e.g. taxation) »Changes in international standards (e.g. MPEG) vCustomers get new ideas as they become aware of system possibilities

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.17 Overcoming Requirements Elicitation Problems u Sommerville and Sawyer give guidelines for addressing these problems vAssess business and technical feasibility for the proposed system vIdentify the people who will help to specify requirements, and understand their organizational bias vDefine the technical environment in which the system will be placed: »Computing architecture, operating system, telecommunications needs vIdentify “domain constraints” that limit system functionality or performance »Characteristics of business environment specific to application domain

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.18 Overcoming Requirements Elicitation Problems (cont.) u Define one or more requirements elicitation methods vInterviews, focus groups, team meetings u Ensure that many people participate so that requirements are defined from different points of view vIdentify and record the rationale for each requirement u Identify ambiguous requirements as candidates for prototyping vA means of addressing volatility u Create usage scenarios to help customers and users better identify key requirements ve.g. Use Cases in OO A&D

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.19 Products of Requirements Elicitation Process u The requirements elicitation process will produce work products to be included in the software configuration vstatement of need and feasibility vbounded statement of scope for the system vlist of customers, users and other stakeholders who participated in requirements elicitation vdescription of system’s technical environment vlist of requirements and their domain constraints »preferably organized by function vset of usage scenarios (under different operating conditions) vany prototypes that were developed u All work products are reviewed by participants in requirements elicitation

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.20 Requirements Analysis and Negotiation u The products of requirements elicitation form the basis for requirements analysis u Requirements analysis vCategorises requirements »Organises them into related sub-sets vExplores relationships between requirements vExamines requirements for »Consistency »Omissions »Ambiguity vPrioritises requirements based on customer/user needs »May lead to plan for incremental development

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.21 Requirements Analysis Questions u Is each requirement consistent with the overall objective for the system? u Have all requirements been specified at the proper level of abstraction? vi.e. not too much technical detail, or exclusion of future possibilities u Is each requirement really necessary? vOr is it an add-on not needed for core system objective? u Is each requirement bounded an unambiguous? u Does each requirement have an attribution? vWho or what is the source of the requirement? u Are there any conflicting requirements? u Is each requirement technically achievable in specified environment? u Is each requirement testable once implemented?

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.22 Requirements Negotiation u It is common for customers/users to ask for more than can be achieved u Also common for different stakeholders to proposed conflicting requirements ve.g. cost requirement from management vs. performance requirement from users vEach party might argue that their requirement is “essential” u Requirements engineer must resolve these conflicts through negotiation: vPrioritize requirements, discuss conflicts in this order vIdentify risks associated with requirements vProduce “guesstimates” of development effort for each requirement u In an iterative process, modify, combine or eliminate requirements so that each stakeholder gets some satisfaction

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.23 Requirements Management u We have noted that changes in requirements: v are essentially unavoidable vwill persist throughout the lifetime of the system u Requirements management helps the project team to identify, track and control requirements and changes to them vThis is closely related to configuration management u Traceability tables are developed for requirements

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.24 Traceability Tables u Features traceability table vShow how requirements relate to customer-observable system features u Source traceability table vIdentify the source of each requirement u Dependency traceability table vShow relationships between requirements u Subsystem traceability table vCategorise requirements according to subsystems they govern u Interface traceability table vShows how requirements relate to internal and external system interfaces

CSE Software Engineering: Analysis and Design, 2003Lecture 3B.25 References u Pressman, R., Software Engineering: A Practitioner's Approach, McGraw-Hill, 2000 (Chapter 10). u Sommerville, I. and Sawyer, P., Requirements Engineering, Wiley, 1997.