Knowledge Sharing

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 Va...

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 ...

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.

What is Requirement? Ans: It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. Its Begin from Communication and continues into the modelling. What is Requirement Engineering? The process of establishing the services that the customer requires from a system and the constraintunder which it operates and is developed. Requirement reflects the needs of customer for a system that serves a certain purpose such as controlling a device, placing an command or finding information. The process of finding out, analyzing, documenting and checking these services and constrains is called requirement engineering (RE). Bridge to design and construction. Example of Types of Requirement