Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity, frequency, reliability »providers, receivers »operational profile (expected scenarios) »stress profile (worst case scenarios)

Dillon: CSE470: ANALYSIS2 Requirements l Specify interfaces »Control interfaces (APIs) »User interfaces - functionality and style »Hardware interfaces l Specify error handling l Identify potential modifications

Dillon: CSE470: ANALYSIS3 Requirements l Identify necessary constraints »performance, security, reliability l Identify areas of risk »alternatives to be explored l Specify validation plans l Specify documentation to be provided

Dillon: CSE470: ANALYSIS4 Analysis Principles l Document reason for specific requirements l Prioritize requirements »High, medium, low l Ignore implementation details »Need to know feasible solutions can be developed »If feasibility is a concern, then propose alternatives to be explored l Be prepared to change

Dillon: CSE470: ANALYSIS5 Reviewing a requirements document l Is it ambiguous? »Carefully define terms and use these terms l Is it consistent? l Is it complete? »Vague requirements »Omitted requirements l Is it verifiable? l Is it realistic? l Does it plan for change? l Does it not overly constrain the problem? l Have alternatives been considered and explored? l Is it clearly presented? »Precise, concise, clear »diagram complex objects and behaviors l Is it what the customer wants?

Dillon: CSE470: ANALYSIS6 Why is requirements analysis difficult? l Communication: misunderstandings between the customer and the analyst »Analyst doesn’t understand the domain »Customer doesn’t understand alternatives and trade-offs l Problem complexity »Inconsistencies in problem statement »Omissions/incompleteness in problem statement »Inappropriate detail in problem statement

Dillon: CSE470: ANALYSIS7 Why is requirements analysis difficult? l Need to accommodate change »Hard to predict change »Hard to plan for change »Hard to forsee the impact of change

Dillon: CSE470: ANALYSIS8 First Law of Software Engineering “ No matter where you are in the system lifecycle, the system will change, and the desire to change it will persist throughout the lifecycle.”

Dillon: CSE470: ANALYSIS9 Reasons for changing requirements l Poor communication l Inaccurate requirements analysis l Failure to consider alternatives l New users l New customer goals l New customer environment l New technology l Competition l Software is seen as malleable Changes made after the requirements are approved increase cost and schedule

Dillon: CSE470: ANALYSIS10 Requirements Products l Specification document »Agreement between customer and developer »Validation criteria for software l Preliminary users manual l Prototype »If user interaction is important »If resources are available l Review by customer and developer »Iteration is almost always required

Dillon: CSE470: ANALYSIS11 Analysis: Steps to follow l Obtain a problem statement l Build an object model and data dictionary l Develop a dynamic model l Construct a functional model l Verify, iterate, and refine the models l Produce analysis document

Dillon: CSE470: ANALYSIS12 Analysis: Object model l Organization of system into classes connected by associations »Shows the static structure »Organizes and decomposes system into more manageable subsystems »Describes real world classes and relationships

Dillon: CSE470: ANALYSIS13 Analysis: Object Model l Object model precedes the dynamic model and the functional model because »static structure is usually better defined »less dependent on details »more stable as the system evolves »easiest model for customer to understand

Dillon: CSE470: ANALYSIS14 Analysis: Object Model l Information comes from »The problem statement »Expert knowledge of the application domain –Interviews with customer –Consultation with experts –Outside research performed by analyst »General knowledge of the real world

Dillon: CSE470: ANALYSIS15 Object Model: Steps to follow l Identify classes and associations »nouns and verbs in a problem description l Create data dictionary entry for each l Add attributes l Combine and organize classes using inheritance

Dillon: CSE470: ANALYSIS16 Analysis: Dynamic model l Shows the time dependent behavior of the system and the objects in it l Expressed in terms of »states of objects and activities in states » events and actions l State diagram summarizes permissible event sequences for objects with important dynamic behavior

Dillon: CSE470: ANALYSIS17 Dynamic Model: Steps to follow l Prepare scenarios of typical interaction sequences l Identify events between objects l Prepare an event trace for each scenario l Build state diagrams l Match events between objects to verify consistency

Dillon: CSE470: ANALYSIS18 Analysis: Functional Model l Shows how values are computed l Data flow diagrams show processes and data flows »processes correspond to activities or actions in dynamic model »data flows correspond to objects or attributes in object model l Best constructed after the object model and dynamic model

Dillon: CSE470: ANALYSIS19 Functional Model: Steps to follow l Identify input and output values l Build data flow diagrams showing functional dependencies l Describe the functions l Identify constraints l Specify optimization criteria

Dillon: CSE470: ANALYSIS20 Analysis: Iteration l Analysis model will require multiple passes to complete l Look for inconsistencies and revise l Look for omissions/vagueness and revise l Validate the final model with the customer