1. OOSE UNIT 2

2. REQUIREMENT ELICITATION CONCEPTS FUNCTIONAL REQUIREMENTS NONFUNCTIONAL REQUIREMENTS COMPLETENESS,CONSISTENCY,CLARITY AND CORRECTNESS REALISM,VERIFIABILITY AND TRACEABILITY GREENFIELD ENGINEERING,REENGINEERING AND INTERFACE ENGINEERING

3. FUNCTIONAL REQUIREMENTS It describe the interactions between the system and its environment independent of its implementation

4. Example for Functional Requirement- Satellite Watch Satwatch is a wrist watch that displays the time based on its current location.Satwatch uses GPS Satellites to determine its location and internal data structures to convert thisl location into a time zone The information stored in satwatch and its accuracy measuring time is such that the watchowner never needs to reset the time.It adjust the time and date displayed as the watch owner crosses time zones and political boundaries Satwatch determine its location using GPS Satellites.During Black out periods,Satwatch assumes that it does not cross a time zone or a political boundary.It corrects its time zone as soon as the blackout period ends. It has two line display showing on the top line,the time and on the bottom line,the date. When political boundaries change,the watch owner may upgrade the software of the watch using webifywatch device and a personal computer connected to the internet.

5. Non-Functional Requirements Non-Functional requirements describe the aspects of the system that are not directly related to the functional behavior of the system FURPS+ Model provides the following categories of non functional requirements. 1)Usability – It is the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. 2)Reliability – It is the ability of a system or component to perform its required functions under stated conditions for a specified period of time. Dependability include Reliability, Robustness and Safety – Robustness – The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environment conditions. – Safety – A measure of the absence of catastrophic consequences to the environment. 3)Performance Requirements – It is concerned with quantifiable attributes of the system such as Response time – How quickly the system reacts to a user input. Throughput – How much work the system can accomplish within a specified amount of time Availability – The degree to which a system or component is operational and accessible when required for use Accuracy 4)Supportability – Requirements are concerned with the ease of changes to the system after deployment Adaptability – The ability to change the system to deal with additional application domain concepts Maintainability – The ability to change the system to deal with new technology or to fix defects Portability – The ease with which a system or component can be transferred from one hardware or software

6. Non-Functional Requirements-contd.. FURPS+ Model provides additional categories of requirements which include 1)Implementation requirement – Constraints on the implementation of the system including the use of specific tools, programming languages or hardware platforms. 2)Interface Requirements – Constraints imposed by external systems including legacy systems and interchange formats 3)Operations requirements – Constraints on the administration and management of the system 4)Packaging requirements – Constraints on the actual delivery of the system.( e. g) constraints on the installation media for setting up the software 5)Legal Requirements – It is concerned with licensing, regulation and Certification issues

7. Quality requirements for Satwatch Any user who knows how to read a digital watch and understands international time zone abbrevations should be able to use satwatch without the user manual[usability requirement] Satwatch should display the correct time zone within 5 minutes at the end of a GPS blackout period.[Performance requirement] Satwatch should accept upgrades via the webify watch serial interface[Supportability requirement] All related software associated with satwatch,including the onboard software will be written using java,to comply with current company policy[Implementation Requirement] Satwatch complies with the physical,electrical and software interfaces defined by webify watch API 2.0[interface requirement]

8. Completeness – All features of interest are described by requirements Example of completeness : The Satwatch specification does not specify the boundary behavior when the user is standing within GPS accuracy limitations of a state’s boundary. Consistent – No two requirements of the specification contradict each other. Example of inconsistency: A watch does not contain any software faults need not provide an upgrade mechanism for downloading new versions of the software. Unambiguous – A requirement cannot be interpreted in two mutually exclusive ways Example of ambiguity – The Satwatch specification refers to time zones and political boundaries. Does the Satwatch deal with daylight saving time or not. Correct – The requirements describe the features of the system and environment of interest to the client and the developer, but do not describe other unintended features. Example of Fault: There are more than 24 time zones. Several countries and territories are half an hour ahead of a neighboring time zone.

9. GreenField Engineering – the developer starts from scratch-no prior system exists – so the requirements are extracted from the users and the client. Re-engineering – It is the redesign and reimplementation of an existing system triggered by technology enablers or by business processes. Interface Engineering - It is the redesign of the user interface of an existing system.

10. REQUIREMENTS ELICITATION ACTIVITIES IDENTIFYING ACTORS IDENTIFYING SCENARIOS IDENTIFYING USE CASES REFINING USE CASES IDENTIFYING RELATIONSHIPS AMONG ACTORS AND USES CASES IDENTIFYING INITIAL ANALYSIS OBJECTS IDENTIFYING NON FUNCTIONAL REQUIREMENTS

11. IDENTIFYING ACTORS QUESTIONS FOR IDENTIFYING ACTORS Which user groups are supported by the system to perform their work Which user groups execute the system’s main functions. Which user groups perform secondary functions, such as maintenance and administration. With what external hardware or software system will the system interact.

12. IDENTIFYING SCENARIOS A scenario is a concrete, focused,informal description of a single feature of the system from the viewpoint of a single actor. Scenarios cannot contain description of decisions. The scenario types include – As-is scenarios Describe a current situation – Visionary scenarios Describe a Future System – Evaluation scenarios Describe user task against which the system is to be evaluated – Training Scenario Tutorial used for introducing new users to the system In FRIENDSYSTEM example the following are the scenarios – Warehouse on fire – Cat in tree – Earthquake

13. Questions for identifying Scenario What are the task that the actor wants the system to perform What information does the actor access? Who creates the data ? an it be modified or removed? By whom Which external language does the actor need to inform the system about ? How often ? When? Which events does the system need to inform the actor about ? with what latency.

14. IDENTIFYING USE CASES Simple USE CASE Writing Guide Use Cases should be named with verb phrases. Actor should be named with noun phrases. The boundary of the system should be clear. Use case steps in the flow of events should be phrased in the active voice. The casual relationship between successive steps should be clear. A use case should describe a complete user transaction. Exceptions should be described seperately. A use case should not describe the user interface of the system A use case should not exceed two or three pages in length.

15. REFINING USE CASES Heuristics for developing scenarios and use cases Use scenarios to communicate with users and to validate functionality Refine a single scenario to understand the user’s assumptions about the system Define many not-very-detailed scenarios to define the scope of the system. Validate with the user. Use mock-ups as visual support only. Present the user with multiple and very different alternatives.

16. IDENTIFYING RELATIONSHIP AMONG ACTOR AND USE CASES COMMUNICATION RELATIONSHIP EXTEND RELATIONSHIP A Behavior that happen anytime or whose occurrence can be more easily specified as an entry condition should be represented with extend relationship. Report Emergency Connection Down > Field Officer

17. IDENTIFYING RELATIONSHIP AMONG ACTOR AND USE CASES Include Relationship A behavior that is strongly tied to an event and that occurs only in a relatively few use cases should be represented with include relationship Open Incident Allocate Resources View Map >

18. Extend versus Include Relationship Heuristics for extend and include relationship Use extend relationship for exceptional, optional or seldom occurring behavior. An example of seldom- occurring behavior is the breakdown of a resource.(e.g ) A fire truck Use include relationship for behavior that is shared across two or more use cases Use discretion when applying the above two heuristics and do not over structure the use case model.

19. IDENTIFYING INITIAL ANALYSIS OBJECTS Heuristics for identifying initial analysis objects Terms that developers or users must clarify to understand the use case Recurring nouns in the use case(e.g incident) Real world entities that the system must track(e.g.,Field Officer) Real world process that the system must track(e.g,Emergency Operation plan) Use Cases(e.g Report Emergency) Data Sources or sinks(e.g.,printer) Always use application domain terms.

20. Managing Requirements Elicitation Negotiating Specifications with Clients:Joint Application Design Maintaining Traceability Documenting Requirements Elicitation The results of the requirement elicitation and the analysis activities are documented in Requirements Analysis Document(RAD)

21. Negotiating specifications with clients:Joint Application Design JAD is a requirements method which consist of five activities Project definition Research Preparation Session Final document

22. Analysis concepts Analysis Object Models and Dynamic Models Entity,Boundary and Control Objects Generalization and Specialization

23. Analysis Object Models and Dynamic models Analysis object model focuses on the individual concepts that are manipulated by the system, their properties and their relationships. The Dynamic Model focuses on the behavior of the system. It includes Sequence diagram and State Charts.

24. Entity,Boundary and Control Objects Entity objects represent the persistent information tracked by the system. year, month and day are entity objects Boundary Objects represent the interactions between the actors and the system Button and LCD Display are boundary objects Control Object are in charge of realizing use cases Changedatecontrol is control object

25. Generalization and Specialization Generalization and Specialization result in the specification of inheritance relationship between concepts. In some instances modelers call inheritance relationships generalization-specialization Incident Low priorityEmergency Disaster Cat In treeEarth QuakeChemical Leak Traffic AccidentBuilding Fire Generalized class Specialized class

26. Analysis Activities:From Use Cases to Objects Identifying Entity Objects Identifying Boundary Objects Identifying Control Objects Mapping Use cases to Objects with sequence Diagram Modeling interactions among objects with CRC Cards Identifying Associations Identifying Aggregates Identifying Attributes Modeling State-Dependent behavior of Individual Objects Modeling Inheritance Relationships Reviewing the Analysis Model

27. IDENTIFYING ENTITY OBJECTS Heuristics for identifying entity objects Terms that developers or users need to clarify in order to understand the use case Recurring nouns in the use cases(e.g.,incident) Real world entities that the system needs to track(e.g.,field officer,dispatcher) Real world activities that the system needs to track(e.g.,emergencyOperationsplan) Data sources or sinks(e.g.,printer)

28. IDENTIFYING BOUNDARY OBJECTS Heuristics for identifying Boundary objects Identify user interface controls that the user needs to initiate the use case(e.g.,ReportEmergencyButton) Identify forms the users needs to enter data into the system(e.g.,EmergencyReportForm) Identify notices and messages the system uses to respond to the user(e.g.,Acknowledgment Notice) When multiple actors are involved in a use case,identify actor terminals(e.g.,DispatcherStation) Do not model the visual aspects of the interfaces with boundary objects Always use the end user’s terms for describing interfaces.

29. IDENTIFYING CONTROL OBJECTS Heuristics for identifying control objects Identify one control object per use case Identify one control object per actor in the use case The life span of a control object should cover the extent of the use case Control Objects for the Report Emergency Use Case Report Emergency Control Manage Emergency Control

30. MAPPING USE CASES TO OBJECTS WITH SEQUENCE DIAGRAM A Sequence diagram ties use cases with objects Sequence diagrams depict the lifetime of objects Heuristics for drawing sequence diagram The first column should correspond to the actor who initiated the use case The second column should be a boundary object The third column should be the control object Control objects are created by boundary objects Boundary objects are created by control objects Entity objects are accessed by control and boundary objects

31. MAPPING USE CASES TO OBJECTS WITH SEQUENCE DIAGRAM Report Emergency Button Report Emergency Control Press() > Report Emergency Form > Fill Contents() Submit() Submit Report() Emergency Report > Manage Emergency Control Submit Report To Dispatcher() > Field Officer

32. MODELING INTERACTIONS AMONG OBJECTS WITH CRC CARDS An alternative for identifying interactions among objects are CRC Cards CRC stands for Classes, Responsibilities and collaborator CRC can be used during modeling sessions with teams

33. EXAMPLE OF CRC CARDS REPORT EMERGENCY CONTROL RESPONSIBILITIES Collect input from Field Officer Control sequence of forms during Emergency Reporting COLLABORATORS EmergencyReportForm EmergencyReport AcknowledgementNotice

34. IDENTIFYING ASSOCIATIONS Heuristics for identifying Associations Examine verb phrases. Name associations and roles precisely. Use qualifiers as often as possible to identify namespaces and key attributes. Eliminate any association that can be derived from other associations. Do not worry about multiplicity until the set of association is stable. Too many associations make a model unreadable.

35. IDENTIFYING AGGREGATES A Composition aggregation indicates that the existence of the parts depends on the whole. A solid diamond indicates composition aggregation. Shared aggregation indicates the whole and the part can exists independently. It is represented as hollow diamond. State Country Township FireStation FireEngineFireFighter Shared Composi tion

36. IDENTIFYING ATTRIBUTES Attributes are properties of individual objects Attributes have Name A brief Description Name A type type Description Emergency Report emergencyType:{fire,traffic,other} Location:String Description:String

37. Heuristic for identifying attributes Examine possessive phrases Represent stored state as an attribute of the entity object Describe each attribute Do not represent an attribute as an object;use an association instead. Do not waste time describing fine details before the object structure is stable.

38. MODELLING STATE DEPENDENT BEHAVIOR-State chart for Incident Active ReportedAssessment ResponseDisengagement InactiveClosedArchived Field Officer arrives on site Dispatcher allocates Resources Field Officer request additional resources Field Officer releases resources All resources deallocated All resources submitted reports When date > 1 yr

39. MODELLING INHERITANCE RELATIONSHIP BETWEEN OBJECTS POLICE OFFICER FIELD OFFICER DISPATCHER

40. MANAGING ANALYSIS Documenting Analysis Assigning Responsibilities Communicating about Analysis Iterating over the Analysis Model Client Sign-Off

41. DOCUMENTING ANALYSIS Requirement Analysis Document 1.Introduction 2.Current System 3.Proposed System 3.1 Overview 3.2 Functional Requirements 3.3 Non-Functional Requirements 3.4 system Models 3.4.1 Scenarios 3.4.2 Use Case Model 3.4.3 Object Model 3.4.3.1 Data Dictionary 3.4.3.2 Class diagrams 3.4.4 Dynamic models 3.4.5 User Interface 4. Glossary

42. ASSIGNING RESPONSIBILITIES END USER CLIENT ANALYST ARCHITECT DOCUMENT EDITOR CONFIGURATION MANAGER REVIEWER

43. COMMUNICATING ABOUT ANALYSIS Contributing Factors include Different backgrounds of participants Different expectations of stakeholders New teams Evolving system

44. ITERATING OVER THE ANALYSIS MODEL The requirements activity can be viewed as several steps Brainstorming – The objective of brainstorming process is to generate as many ideas as possible without necessarily organizing them. Solidification – Functionality is organized into groups of use cases with their corresponding interfaces. Maturity – When changes are necessary, the client and developer define the scope of the change and its desired outcome and change the analysis model.

45. CLIENT SIGN-OFF The client sign off represents the acceptance of the analysis model by the client.In addition they agree on A list of priorities(High,Medium,Low) A revision Process A list of criteria that will be used to accept or reject the system A schedule and Budget

46. An example of revision process Client Developer Report Problem or Change Request Review Proposed change Design Change Update Requirements Archive Request Design Test Update Design Update Code Review actual change Execute all relevant test Change approved