Your SlideShare is downloading. ×
  • Like
Object oriented analysis &design - requirement analysis
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Object oriented analysis &design - requirement analysis


object oriented analysis and design. …

object oriented analysis and design.
requirement analysis.
what is requirement?
types of requirement.
functional requirements.
nonfunctional requirements.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Object Oriented Analysis &design Requirement Analysis References : OOAD by timothy. OOAD by tulsiram sule.(techmax) Presentation by Abhilasha Lahigude
  • 2. Requirements  What o o is a requirement? Definition: A requirement is a statement describes either 1) an aspect of what the proposed system must do, or 2) a constraint on the system’s development. In either case, it must contribute in some way towards adequately solving the customer’s problem; the set of requirements as a whole represents a negotiated agreement among all stakeholders. i.e. requirement is a relatively short and concise piece of information/statement about what the projected system will do and how the system will be developed and all the stakeholders have agreed on it.
  • 3. Requirement o Let us dissect this definition in order to better understand it: • A requirement is a statement…: this means that each requirement is a relatively short and concise piece of information, expressed as a fact. It can be written as a sentence or can be expressed using some kind of diagram. We will call a collection of requirements a requirements document. • …an aspect of what the proposed system must do…: most requirements say something about the tasks the system is supposed to accomplish. They do not describe the domain. • …a constraint on the system’s development…: requirements often specify the quality levels required. They may also specify details such as the programming language to be used if this is truly important to the customer. They should, however, avoid discussing incidental aspects of the design. • …contribute … towards adequately solving the customer’s problem: a requirement should only be present if it helps solve the customer’s problem – as we discussed in Chapter 1, this is what software engineering is all about. • …a negotiated agreement among all stakeholders…: a statement about the system should not be declared to be an official requirement until all the stakeholders (users, customers, developers and their management) have reviewed it, have negotiated any needed changes, and have agreed that it is valid
  • 4. Types of requirements  Requirements major types: 1. 2. can be divided into two Functional. non-functional(quality, performance, design, platform and process).
  • 5. Functional Requirements  Functional requirements describe what the system should do; i.e., they describe the services provided for the users and for other systems.  The functional requirements discuss the functionality required by the users from the system.  functional 1) 2) requirements should include : everything that a user of the system would need to know regarding what the system does, and everything that would concern any other system that has to interface to this system. Details that go any deeper into how the requirements are implemented should be left out.
  • 6. Functional Requirements  The functional requirements can be further categorized as follows: o What inputs the system should accept, and under what conditions. This includes data and commands both from the users and from other systems. o What outputs the system should produce, and under what conditions. Outputs can be to the screen or printed. They can also be transmitted to other systems, such as special I/O devices, clients or servers. o What data the system should store that other systems might use. This is really a special kind of output that will eventually become an input to other systems. Data (e.g. the specifics of a file format used to temporarily back up some data) can be ignored until the design stage. What computations the system should perform. The computations should be which is stored for the exclusive use of this system o described at a level that all the readers can understand. For example, you would describe a sorting process by saying that the result is to be ordered in ascending sequence according to the account number. You would not normally specify the particular algorithm to be used. o The timing and synchronization of the above. Not all systems involve timing and synchronization – this category of functional requirements is of most importance in hard (e.g. telecommunications systems, systems that control power plants or factories, and systems that run automobiles and airplanes). real-time systems that do such things as control hardware devices
  • 7. Non-functional Requirements A Non-functional requirement is a statement of how a system must behave; it is a constraint upon system’s behaviour.  Non-functional requirements can be categorized as: o o o o o Quality constraint. Performance constraint. Design constraint. Environmental / platform constraint. Process constraint.
  • 8. Non-functional Requirements Quality Constraint: Quality constraints reflects the quality attributes. These quality requirements constrain the design to meet specified levels of quality. Following are some quality attributes:  Maintainability and Enhancement:In order to ensure that the system can be adapted in the future, you should describe changes that are anticipated for subsequent releases. This constrains design and improves quality without adding explicit new functional requirements.  Reusability: Reusability is the likelihood a segment of source code that can be used again to add new functionalities with slight or no modification. Reusability reduces implementation time as reusable model is already tested.  Reliability: Reliability is specified by using mean time to failure. It is the ability of a system to perform its functions under stated conditions for a specified period of time.
  • 9. Non-functional Requirements Performance constraints: Response time: Response time is time system take to compute the result. Low response time is desirable. Throughput: It is number of computation or transactions per unit time. Some systems take long time for processing or Some systems are continually responding to client , it is necessary to consider throughput. Utilization: Utilization is resources consumed by the system. Utilization of resources such as memory or network bandwidth are specified. E.g. system should not use more than 20MBPS of bandwidth.
  • 10. Non-functional Requirements Design constraints:  Availability: Availability measures the amount of time that a server is running and available to respond to users. E.g. System should not down for more than 5 minutes.  Recovery from failure: If the hardware or software crashes, or the power fails, then the system will be able to recover within a certain amount of time, and with a certain minimal loss of data.
  • 11. Non-functional Requirements Environmental/Platform constraints: Platform: Platform specifies the hardware and operating system used for developing system. E.g. Linux operating system with 2GB RAM. Technology to be used: It signifies the programming language (framework) used to develop a system. Sometimes client places constraint on programming language to be used for developing system. E.g. System should be developed by using java language.
  • 12. Non-functional Requirements Process constraints:  Development process to be used: In order to ensure quality, some requirements documents specify that certain processes be followed; E.g. particular approaches to testing. The details of the process should not be included in the requirements; instead a reference should be made to other documents that describe the process.  Cost and delivery date.
  • 13. Thank you !