Chapter 10/11 System Engineering AND Analysis Concepts and Principles

1. Chapter 10/11System EngineeringAND Analysis Concepts and Principles

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.

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.

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.

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

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

7. Types of Requirements Engineering • Information Engineering • Traditional Engineering • Viewpoint Requirements Engineering • Scenario Requirements Engineering • Model/Method Oriented Engineering

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

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

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

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

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

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

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

15. Product Architecture Template

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

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.

18. Traditional Requirements EngineeringComponents • 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.

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.

20. Requirements Engineering R e q u i e m e n t s F e a s i b i l i t y e l i c i t a t i o n a n d s t u d y a n a l y s i s R e q u i r e m e n t s s p e c i f i c a t i o n Feasibility Report R e q u i r e m e n t s v a l i d a t i o n System Models User and System Requirements Requirements Document

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.

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

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

24. Requirements Elicitation and Analysis Process R e q u i r e m e n t s d e f i n i t i o n a n d s p e c i f i c a t i o n R e q u i r e m e n t s v a l i d a t i o n D o m a i n P r i o r i t i z a t i o n u n d e r s t a n d i n g P r o c e s s e n t r y R e q u i r e m e n t s C o n f l i c t c o l l e c t i o n r e s o l u t i o n C l a s s i f i c a t i o n

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.

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

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

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

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

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.

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?

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

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

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?

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

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

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.

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.

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

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.

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)