Understanding Requirements of System

1. Understanding Requirements of System • Requirements engineers need to understand many aspects of the system: (e.g.) • Services (functions and information) the system must provide • Application domain of the system • Constraints (non-functional) on the system • Environment where system is to be installed and runs • Organizational issues affecting system’s operations • The users, their backgrounds and biases • To understand and capture multiple perspectives, requirements methods must not be a rigidly structured scheme. (Yet, no structure would be ineffective)

2. View Point Oriented Methods • “A Viewpointis a collection of information about a system or about a related problem, environment or domain which is collected from a particular perspective” from some of the following: • Different end users (by job categories) • System developers (by development phases) • User support and maintenance • Other systems which interface with this • Systems managers • Trainers • Sales and Marketing • Paying customer (not necessarily end-users) • These different views arise because of the different “roles” (above list) that each agent plays Viewpoint Oriented methods explicitly recognize the diversityof sources of requirements’ viewpoints and provide a way to organize the varied information

3. Viewpoint Orientation Requirements = ∑ (viewpoints) Advantage : More Complete Disadvantage: Inconsistent & Conflicting But With proper integration and conflict resolution, improved ∑, we should have a: - more complete - more clear - better integrated - consistent

4. Main Objectives of Viewpoint Oriented Methods • Discovery & preservation of multiple perspectives (views) on a domain • Ensure consistency among these perspectives (views)

5. View Point Oriented Methods • Structured Analysis and Design Technique (SADT) • Controlled Requirements Expression (CORE) • Viewpoint-oriented System Engineering (VOSE) • Viewpoint-oriented Requirements Definition (VORD) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

6. Structured Analysis Design Technique (SADT) • Developed in the late 1970’s by D. Ross • Based on Data-Flow model • Uses the simple “box and arrow” diagram • Recognizes the diverse perspectives, but implicitly show it through its source and sinks of data • Diagram includes: • Box for processing • Set of 4 arrows which have different meanings 1. left arrow is data input to the processing 2. right arrow is the output from the processing 3. top arrow represents control and other information for facilitating processing 4. bottom arrow represents the mechanism or algorithm to be used for processing Control processing Input Output Mechanism

7. Example of implicit viewpoints item db user db Lib card Library item Check_out user checked item user Lib item user librarian Return info check-out processing The source and sink of information in SADT are implicitly the viewpoints. - user : both source and sink - librarian : source - user db : source - item db : source

8. Another example of implicit viewpoints customer db Item inventory db Customer Purchase Processing Items invoice order customer customer Invoice computation & inventory update

9. Example of “decomposing” SADT Diagram( a portion of Order Processing) Updated inventory info Item inventory customer order item Customer info A buyer Check order Item details customer purchase request Item sold Inventory processing buyer Process purchase Customer invoice Customer Credit processing SADT Diagrams have been used for both requirements and high level design.

10. Controlled Requirements Expression (CORE) • Developed in the late 1970’s (by Mullery) • Mainly used in Europe • Like SADT, based on functional decomposition • Different from SADT, CORE explicitly expresses the notion of viewpoints • The producer of requirements with CORE is aiming at satisfying: • Implementers who will use the requirements to develop the system and show that it is done correctly • Users and customers of the system so that they can see that it will do what they want • Other requirements analysts who can use this information to better define their requirements Similar to SADT, CORE can be used for requirements and high level design.

11. CORE Steps • Composed of the following steps: • Identifyviewpoints • Structure viewpoints into Bounding and Defining viewpoints (see next slide) • Collecting information into a tabular form • Decomposing data into its constituents parts and formulating a data dictionary • Modeling each viewpoint (similar to SADT diagram) • Combining the modeled viewpoints • Perform constraint analysis of the whole system hardest part of CORE

12. Viewpoint Identification and Structuring - - - - - - - purchaser check order 1) List all the viewpoints: all the entities in the system and those that interact with the system ------- do you have to elicit for viewpoints? Bounding viewpoints: Defining viewpoints: purchaser check order . . . . Inventory db Issue invoice 2) structure the viewpoints: i) Bounding viewpoints – external entities that exchange info with system ii) Defining viewpoints – sub-processes of the system of interest

13. Forming Tabular Collection of Viewpoint • Each viewpoint is developed: • - source of the data • - input data used for processing • - processing action • - output data from the action • - destination of the output data

14. Remaining Steps of CORE Customer • Data decomposition & structuring: • This is the same as taking each data item and listing its attributes • Developing viewpoint model • Develop combined viewpoint model • Constraint analysis • Performance • Capacity • security Customer id # Name Address Sex Birth-date Credit status Item inventory Customer info customer order item Check order Item details customer purchase request Process purchase related mostly to internal (defining) viewpoints

15. Viewpoint-Oriented System Engineering (VOSE) • VOSE was originally proposed as a framework for integratingdevelopment methods utilized in development of large, complex systems; it addresses the entire system development with a variety of participants (each with different views) • Each participant’s role in development process and his/her specific view of the problem domain is captured • The VOSE viewpoint is a template which includes: • A Style or a scheme of representing the view (e.g. designer and req. analyst may use different notational diagrams) • Work-plan that describes the development strategy that uses the style to produce the specification • The problem domain ( the particular perspective of) described with the style • Specification of the problem produced according to the Work-Plan • Work history and the current development state • Each viewpoint is associated with a particular developer --- a viewpoint owner. • VOSE viewpoints (completed templates) are then grouped and analyzed for conflicts and resolved

16. Using the same Style and Work-plan template STYLE: Use Case Diagram to show actors and system’s functional interaction • Work-plan: • Use scenarios to show high level • requirements • Identify actors • identify the processing function • associated with each actor • Link the actors to the functions • Draw the system boundary View 1 View 2 View 3 Problem Domain Description 2 (actor 2 perspective) Problem Domain Description 3 (actor 3 perspective) Problem Domain Description 1 (actor 1 perspective) Actual Specification in Use Case diagram Actual Specification in Use Case diagram Actual Specification in Use Case diagram Work record Work record Work record

17. same style but -- different problem domain (view) 1) “simple” states of the item (book) from student user perspective (domain) with user on shelf off shelf check out remove 2) “simple” states of the item (book) from librarian perspective (domain) In-lib (avail.) In-lib (avail.) Check out Out of Library (~avail.) return

18. Different Checks for Consistency functional area 1 functional area 2 different domains data flow model customer Consistency of Modeling and depth Compare Consistency Of views Consistency of “depth” of view State transition model data flow model clerk State transition model Rarely happens

19. Checking and Resolving Conflicts in the Viewpoints • Look a the different viewpoints, describing the samefunctional area(using the same Style and Work-plan) but from different domainperspective. • They should have “equal” and consistent specification • Look at the different viewpoints, describing differentfunctional areas (using the same Style and Work-plan) but from same domain perspective • They should be consistent in the way specification is written ( same style gives some consistency --- but the depth level may still differ.) • Rarely will there be different Style or Work-plan to portray the same domain • and the same requirements specification • (as the book portrays with State diagram and DFD) • ** Book example happens when the requirements analyst specifies the system in one Style and the designer specifies the same system with another Style **

20. Viewpoint-Oriented Requirements Definition (VORD) • VORD is another variation on handling requirements with viewpoints • It was introduced by Kotonya and Sommerville to handle mostly interactive systems • VORD defines 2 fundamental classes of viewpoints: • Direct Viewpoints: These correspond directly to the clients of the system who receive services from the system and interacts with the system (through entering data and control information). • Indirect viewpoints: These correspond to those who have interests (via putting constraints or expectations) in the services of the system but do not interact directly with the system themselves

21. Examples of VORD direct and indirect viewpoints • Direct viewpoints are mostly the functional capabilities that the system needs to provide • Indirect viewpoints may be one of the following: • Engineering oriented by those who are concerned with software design, implementation, etc. • e.g. maintainability or development platform • Organizational oriented by those who are concerned with the impact of the system on the organization • e.g. limiting access (or knowledge) by only certain groups in the organization for security concerns • Externally oriented by those who are concerned with the influences on the external environment • e.g. safety to the users of the system or abiding to the industry standards

22. Simple Examples of VORD for a Payroll System • A human resource clerk who is concerned with ensuring that if there is an exception, he/she can fix the record and input into the system in time to still produce the regular paycheck for that employee – (direct viewpoint or indirect viewpoint?) • A systems analyst who is concerned with having the payroll system meeting all the state and federal laws for the generation of W-2’s each year – (direct viewpoint or indirect viewpoint?) • An office manager who is concerned with the security impact of the system which generates paper paychecks versus direct deposits – (direct viewpoint or indirect viewpoint?) • An employee who is concerned with the inquiry function of the system that allows her/him to view their payroll record on-line – (direct viewpoint or indirect viewpoint?)

23. VORD process model - - - abstract viewpoints and requirements Identify viewpoints Document viewpoints Analyze requirements specify requirements Requirements Information File Note: 1. this is an iterative process 2. various viewpoint requirements are inputted, but needs to identify the “relevant” ones. 3. analysis is composed of checking for conflict/consistency, clarity, completeness 4. the specification may use multiple notations (formal and informal ones)

24. Graphical Notation of Viewpoints “Tree” v1 System initialization System backup direct System operation viewpoint indirect V1 – system initialization is performed by ---- and -------- 1. The decomposition (specialization) of a viewpoint is from left to right. 2. The actual documentation of the viewpoint is in a separate place

25. Graphical Notation of a Viewpoint viewpoint identifier Viewpoint type Viewpoint Label (or name) [ a1 l attribute ] [ a2 l attribute ] attribute identifier

26. A Viewpoint Template • VORD uses standard templates to record viewpoint and requirement information. A viewpoint template comprises: • A viewpoint identifier number • A viewpoint name or label • Description of the role of the viewpoint in the problem domain • A viewpoint type (Traces the viewpoint to its parent class – service or non-functional) • Attributes that characterize the viewpoint in the problem domain. Attributes represent the control information supplied by the viewpoint to the system. • Event scenarios that describe the interaction between the viewpoint and the system. • Viewpoint specializations or subclasses. • Viewpoint history that describes the evolution of viewpoint requirements (e.g. source of viewpoint)

27. Sample Documenting of Initial RequirementsUsing partial VORD viewpoint template Viewpoint Requirements ID Label Description Type Source 2.0 Bank staff 2.0.1 provides access to administrative sv 3.1 services based on valid staff PIN and access permission set for the bank staff 2.1 Bank Manager 2.1.1 provides transaction reports sv 2.1 2.1.2 bank managers needs transaction reports on a daily basis nf 2.1 2.2 ATM operator 2.2.1 provide system startup and sv 3.1 shutdown based on valid operator PIN and authorization 2.2.2 provide mechanism to page the sv 2.2 to ATM operator when ATM funds are low 2.2.3 failure rate of operator paging is below nf 2.2 1/1000 2.3 Bank teller 2.3.1 provide cancellation of cash card sv 3.1 in the event of loss or cancellation of card 2.3.2 provide cash card cancellation within nf 3.1 3 minutes of request of cancellation

28. Requirements Validation via Viewpoint Resolution • A requirements validation method (for completeness and correctness) suggested by Leite and Freeman in the early 1990’s. It requires at least 2 analysts and is based on 3 notions: • Viewpoint, which is the mental position of the world used by the person who plays that specific role • Perspective, which is a set of information observed and modeled according to the viewpoint • View, which is the integration of the perspectives (requirement based on the specific viewpoint)

29. Requirements Validation via Viewpoint Resolution Model (Leite and Freeman) Perspectives develop data View 1 Resolve issues process Analyst 1’ viewpoint actor hierarchy “Validated” View Resolve conflicts View 2 Analyst 2’s viewpoint