22 April 2012

Analysis Model

Elements of the Analysis Model













1. Scenario Based Element

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

20 April 2012

Software Analysis

Software analyses are dividing into five parts:
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.

11 April 2012

Use Case Diagrams

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

07 April 2012

Requirement Management

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.

Steps of Requirement Engineering

  • 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: customer concept and the software functional behaviors are same or not - defined
    • Examine all requirements are fulfilled and understood
    • Formal technical review

What is Non-functional requirements

  • 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 affect the overall architecture of a system rather than the individual components.
    • For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.

What is 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 name in an individual clinic. User chooses clinic then search.

Requirements completeness and consistency

  • In principle, requirements should be both complete and consistent.
    • Complete-They should include descriptions of all facilities required.
    • Consistent-There should be no conflicts or contradictions in the descriptions of the system facilities.
  • In practice, it is impossible to produce a complete and consistent requirements document.

Types of requirement

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.

Content are helpful for you?

Follow by Email