Knowledge Sharing

Elements of the Analysis Model 1. Scenario Based Element Use case Diagram Use-cases Text Activity Diagrams Swim Lane Diagrams 2. Class Based Element Class Diagram Analysis Packages CRC Models Collaboration Diagrams 3. Flow Oriented elements Data Flow Diagram Control Flow Diagrams Processing Narratives 4. Behavioral elements State Diagrams Sequence Diagrams I will discuses all things one by one

Software analyses are dividing into five parts: Analysis Modelling Project Management Project planning and Scheduling Project Estimation Quality Management Objectives of analysis model To describe what the customer require. To establish a basis for the creation of a software design. To define a set of requirements that can be validated once the software is built What is a model? Ans:a model is a simplification of reality Why do we model? -we build models so that we can better understand the system we are developing. -we build models of complex systems because we cannot comprehend such a system in its entirety. -four aims to achieve:- 1. help us to visualize a system. 2. permit us to specify the structure/behavior of a system. 3. give us a template that guides us in constructing systems. 4.document the decisions we have made.

Use Case Diagrams: A use case in software engineering and systems engineering is a description of a system’s behavior. In other words, a use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements.  Actor: An actor represents a set of roles that users of use case play when interacting with these use cases. Actors can be human or automated systems. Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions. Use Case Diagram for School Management Fig: Use Case Diagram for School Management Use Case Diagram for Point of Sale Fig: Use Case Diagram for Point of Sale

Traceability Tables Features traceability table: Shows how requirements relate to important customer observable system/product features. Source traceability table: Identifies the source of each requirement. Dependency traceability table: Indicates how requirements are related to one another. Subsystem traceability table: Categorizes requirements by the subsystem(s) that they govern. Interface traceability table: Shows how requirements related to both internal and external system interfaces.

Inception:  define scope and nature  How does a software project will started  Define business plan Identify breath and depth of market Rough feasibility analysis Identify working description Elicitation: help customer to define what is required Time to come out Problem of scope Boundary, avoid unnecessary technical details Problem of understanding Not sure about need Problem of volatility Requirement changing Elaboration: basic requirements are found and modified Inception and elicitation expanded and refined It is analysis modeling action Relationship and collaboration between classes are identified and generate use case diagram Negotiation: priorities, what is essential, what is required to maintain –defined Ahead to analysis Cost estimation, delivery time, elimination - combination – modification of requirements Specification: problems are specified Written document Set of graphical or mathematical model Collection of scenario Prototype of combination of these Validation: cus

These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. i.e. Deactivate or delete record after 24 hrs Process requirements may also be specified mandating a particular programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. Types of Nonfunctional requirement Product requirement: Examples The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement:  Examples Users of the MHC-PMS system shall authenticate themselves using their health authority identity card. External requirement:  Examples The system shall implement patient privacy. Non-functional requirements implementation Non-functional requirements may affec

Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. Examples: Functional requirements for the MHC-PMS A user shall be able to search the appointments lists for all clinics. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Each staff member using the system shall be uniquely identified by his or her 8-digit employee number. Requirements imprecision Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Consider the term ‘search’ in requirement 1 User intention – search for a patient name across all appointments in all clinics; Developer interpretation – search for a patient nam

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’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. 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. May state what the system should not do. Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services.