2. 1 Chapter 10/11 System Engineering AND Analysis Concepts and Principles

3. 2 Requirement  A REQUIREMENT may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.  This multiplicity is inevitable as requirements may serve multiple functions.  Also there are various types of requirements.

4. 3 Types of Requirements  User requirements-- Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers  System requirements-- A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor  Software specification-- A detailed software description which can serve as a basis for a design or implementation. Written for developers.

5. 4 Types of Requirements  Functional requirements-- Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.  Non-functional requirements-- constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.  Domain requirements-- Requirements that come from the application domain of the system and that reflect characteristics of that domain.

6. 5 Requirements Engineering  The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements  However, there are a number of generic activities common to all processes  Requirements elicitation  Requirements analysis  Requirements validation  Requirements management

7. 6 The Hierarchy World view Business or Product Domain Domain of interest Domain view System element Element view Detailed view

8. 7 Types of Requirements Engineering  Information Engineering  Traditional Engineering  Viewpoint Requirements Engineering  Scenario Requirements Engineering  Model/Method Oriented Engineering

9. 8 Information Engineering (IE)  uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise  focuses first on the enterprise and then on specific business areas  creates enterprise models, data models and process models  creates a framework for better information management distribution, and control

10. 9 The IE Process Stages  Information strategy planning (ISP)  strategic goals defined  success factors/business rules identified  enterprise model created  Business area analysis (BAA)  processes/services modeled  interrelationships of processes and data  Application Engineering  a.k.a... software component engineering  modeling applications/procedures that address (BAA) and constraints of ISP  Construction and delivery  using CASE and 4GTs, testing

11. 10 Information Strategy Planning (ISP)  Management issues  define strategic business goals/objectives  isolate critical success factors  conduct analysis of technology impact  perform analysis of strategic systems  Technical issues  create a top-level data model  cluster by business/organizational area  refine model and clustering

12. 11 Defining Objectives and Goals (ISP)  Objective—general statement of direction  Goal—defines measurable objective: “reduce manufactured cost of our product”  Subgoals:  decrease reject rate by 20% in first 6 months  gain 10% price concessions from suppliers  re-engineer 30% of components for ease of manufacture during first year  objectives tend to be strategic while goals tend to be tactical

13. 12 Business Area Analysis (BAA)  define “naturally cohesive groupings of business functions and data” (Martin)  perform many of the same activities as ISP, but narrow scope to individual business area  identify existing (old) information systems / determine compatibility with new ISP model  define systems that are problematic  defining systems that are incompatible with new information model  begin to establish re-engineering priorities

14. 13 The BAA Process sales acct manufacturing QC eng’ring distribution admin. Process Decomp. Diagram Matrices e.g., entity/ process matrix Process Flow Models Data Model

15. 14 Product Engineering System analysis (World view) The complete product capabilities Component engineering (Domain view) Processing requirement Analysis & Design Modeling (Element view) Construction & Integration (Detailed view) software function Software Engineering program component hardware data behavior

16. 15 Product Architecture Template

17. 16 Architecture Flow Diagram bar code reader subsystem bar code decoding subsystem data base access subsystem shunt control subsystem report formating subsystem diagnostics subsystem operator interface subsystem shunt controller mainframe communications driver operator requests CLSS queries, reports, displays shunt control status bar code acquisition request bar code pulse tach input line speed bar code reader status sensor status raw bar code data part number report requests bin location key sort records formated reporting data sorting reports shunt commands CLSS reports BCR status shunt status communications status timing/location data operator interface data acquisition interface diagnostic interfaceoutput interface CLSS processing & control sensor data acquisition subsystem

18. 17 Traditional Engineering  Traditional engineering techniques for gathering and documenting requirements has a slightly different focus than the information engineering focus on strategic planning and enterprise orientation.

19. 18 Traditional Requirements Engineering Components  Elicitation — determining what the customer requires by interviewing, holding Joint Application Development (JAD) sessions, or simply taking to the user(s).  Analysis & negotiation — understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result.  Requirements specification — building a tangible model or models for requirements.

20. 19 Requirements Engineering  System Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistency (example process, data, scenario, or event model).  Validation — reviewing the model for correctness, completeness, and consistency.  Management — identify, control and track requirements and the changes that will be made to them.

21. 20 Requirements Engineering Feasibility study Requiements elicitation and analysis Requirements specification Requirements validation Feasibility Report System Models User and System Requirements Document

22. 21 Feasibility Study  A feasibility study decides whether or not the proposed system is worthwhile  The input to the feasibility study is outline description of the system and how it will be used within an organization.  The results of the feasibility study should be a report which recommends whether or not it is worth carrying on with requirements engineering and system development process.

23. 22 Elicitation and Analysis  Sometimes called requirements elicitation or requirements discovery  Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints  May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders

24. 23 Elicitation and Analysis  Elicitation and analysis is a difficult process for a number of these reasons:  Stakeholders don’t know what they really want  Stakeholders express requirements in their own terms  Different stakeholders may have conflicting requirements  Organisational and political factors may influence the system requirements  The requirements change during the analysis process. New stakeholders may emerge and the business environment change

25. 24 Requirements Elicitation and Analysis Process Requirements validation Domain understanding Prioritization Requirements collection Conflict resolution Classification Requirements definition and specification Process entry

26. 25 Activities  Domain understanding— Analyst must develop their understanding of the application domain.  Requirements collection— This is the process of interacting with stakeholders in the system to discover their requirements.  Classification— This activity takes the unstructured collection of requirements and organized them into coherent clusters  Conflict resolution— Inevitably, where multiple stakeholder are involved, requirements will conflicts  Prioritisation— In any set of requirements some will be important than others.  Requirements checking— The requirements are checked to discover if they are complete, consistent and in accordance with what stakeholders really want from the system.

27. 26 ViewPoint Oriented Elicitation  In viewpoint oriented elicitation, the main stakeholders are the focus for gathering requirements  Stakeholders represent different ways of looking at a problem or problem viewpoints  This multi-perspective analysis is important as there is no single correct way to analyse system requirements  Types of viewpoint:  Data sources or sinks--Viewpoints are responsible for producing or consuming data. Analysis involves checking that data is produced and consumed and that assumptions about the source and sink of data are valid

28. 27 Scenario Based Elicitation  In scenario based elicitation the main focus is defining the different scenarios of the business area.  Scenarios are descriptions of how a system is used in practice  They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system  Scenarios are particularly useful for adding detail to an outline requirements description  Scenario descriptions:  System state at the beginning of the scenario  Normal flow of events in the scenario  What can go wrong and how this is handled  Other concurrent activities  System state on completion of the scenario

29. 28 Use Case Based Elicitation  In use case elicitation, the focus is on the use cases of the business areas.  Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself  A set of use cases should describe all possible interactions with the system  Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system

30. 29 Requirements Validation  Concerned with demonstrating that the requirements define the right system.  (the system the customer really wants)  Requirements error costs are high so validation is very important  Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error

31. 30 Requirements Validation  Steps involved in validating requirements:  The need of the user should be shown to be valid—A user may think that a system is needed to perform certain functions but further though and analysis may identify additional or different needs and any set of requirements is inevitably a compromise across the user community.  The requirements should be shown to be consistent. Any one requirement should not conflict with any other.  The requirements should be shown to be complete—The definition should include all functions and constraints intended by the system user.  The requirements should be shown to be realistic—There is no point in specifying requirements which are unrealizable. It may be acceptable to anticipate some hardware developments but developments in software technology are much less predictable.

32. 31 Requirements Validation  Validity.  Does the system provide the functions which best support the customer’s needs?  Consistency.  Are there any requirements conflicts?  Completeness.  Are all functions required by the customer included?  Realism.  Can the requirements be implemented given available budget and technology  Verifiability.  Can the requirements be checked?

33. 32 Requirements Validation Techniques  Requirements reviews -- Systematic manual analysis of the requirements  Prototyping -- Using an executable model of the system to check requirements.  Test-case generation — Developing tests for requirements to check testability  Automated consistency analysis -- Checking the consistency of a structured requirements description

34. 33 Reviews  Regular reviews should be held while the requirements definition is being formulated  Both client and contractor staff should be involved in reviews  Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage

35. 34 Review Checks  Verifiability--Is the requirement realistically testable?  Comprehensibility--Is the requirement properly understood?  Trace ability--Is the origin of the requirement clearly stated?  CASE tool support--Adaptability. Can the requirement be changed without a large impact on other requirements?

36. 35 Requirements Management  Requirements management is the process of managing changing requirements during the requirements engineering process and system development  Requirements are inevitably incomplete and inconsistent  New requirements emerge during the process as business needs change and a better understanding of the system is developed  Different viewpoints have different requirements and these are often contradictory

37. 36 Requirements Change  The priority of requirements from different viewpoints changes during the development process  System customers may specify requirements from a business perspective that conflict with end-user requirements  The business and technical environment of the system changes during its development

38. 37 The Requirements Document  The requirements document produced may have many names.  IEEE refers to it as a SRS – System Requirements Specification  Your text refers to it as simply a requirements document  Since this is a software engineering course we will follow the the SRS by IEEE.  In the next section, we will describe the contents of the IEEE SRS.

39. 38 Software Specification Tools- Data Dictionary One of the requirements of the specification document is the data dictionary. A data dictionary is an important tool for software development. The data dictionary- alias encyclopedia - alias repository may contain many items of information. Data Dictionary - for interfaces (inputs, outputs, external interfaces), data entities, data elements (attributes), use cases, classes.

40. 39 Software Specification Tools- Data Dictionary DeMarco Notation = is composed of + and [ / ] either/or { } n repetitions (n times) ( ) optional * * comments

41. 40 Software Specification Tools- Data Dictionary It should include: Name (of the item) Type (use case, input, output, external interface, class, class or entity element(attribute), class operation…..) Description Composition definition using Demarco notation other data as needed ONLY ONE ENTRY with the same name AND type.

42. 41 Software Specification Tools- Data Dictionary Example of composition (using demarco) SRF = student ssn + student name + (student address + classification) + { class information} class information = class prefix + class number + section number + reference number + ( building number + room number)