Your SlideShare is downloading. ×
Software Requirements Engineering Methodologies
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Software Requirements Engineering Methodologies

8,742
views

Published on

Published in: Education, Technology

1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
8,742
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
250
Comments
1
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1.
    • Presented by:
            • 08-SE-59
            • 08-SE-69
            • 08-SE-75
  • 2. What is a software requirement engineering methodology?
    • An organized, documented set of rules and practices for gathering requirements
  • 3. Methodologies
    • Some techniques employed are:
    • Storyboarding
    • Prototyping
    • State Transition diagrams
    • Use cases
    • Modeling
  • 4. What is a Story board…?
    • A visual flexible process of sorting ideas.
    • Combines brainstorming and affinity diagramming.
    • A series of illustrations or images displayed in sequence for the purpose of pre-visualizing the requirements.
    • A Storyboard "tells a specific story".
  • 5. What do storyboards do?
    • In software, storyboards are used most often to work through the details of the human-to-machine interface.
    • In this area, generally one of high volatility, each user is likely to have a different opinion of how the interface should work.
    • Storyboards for user-based systems deal with the three essential elements of any activity:
          • Who the players are
          • What happens to them
          • How it happens
  • 6. Who uses storyboards?
      • S ystem analysts
      • U ser-interface designers
      • D esigners
      • T hose who test the system's features .
      • T he manager
  • 7. Types of Storyboards
    • Passive storyboards
    • Consist of sketches, pictures and screenshots etc
    • Active storyboards
      • Makes the user see a movie
      • Provide an automated of the system.
    • Interactive storyboards
      • Require participation by the user .
  • 8. Benefits of Storyboards
    • A storyboard serves multiple purposes
      • helps understand how requirements impact implementation and test
      • describes how a system or part of a system is intended to work “before the fact”
      • documents system functionality
    • Communicate and verify functionality with relevant stakeholders
  • 9. Benefits of Storyboards (cont.)
    • Because storyboards exist independently of the software system they describe, they have many advantages over other methodologies
      • They cannot crash,
      • very easy to share with large groups
      • do not give the false impression that the system is already developed.
      • feedback is easier to accommodate.
    • Storyboards, like HCIs and GUIs, communicate design notions more clearly to users than use cases alone can.
  • 10. Limitation
    • One of the biggest problems with storyboards is that they can become outdated very quickly. User interfaces originally defined often change over time, and that creates a maintenance burden.
  • 11. Tips for storyboard
    • Don't invest too much in a storyboard.
    • If you don't change anything, you don't learn anything..
    • Don't make the storyboard too functional.
    • Whenever possible, make the storyboard interactive.
  • 12. What is Prototyping…?
    • A methodology to gather and validate requirements for rapid software development.
    • A modified method for the solution to the requirements analysis.
    • A visualization of an application that hasn't yet been constructed.
  • 13. Prototyping Process Establish Prototyping Objectives Define Prototyping Functionality Develop Prototype Evaluate Prototype Prototyping Plan Outline Definition Executable Prototype Evaluation Report
  • 14. Prototyping in the software process
    • Evolutionary or operational prototyping
      • an initial prototype is produced and refined through a number of stages to the final system.
    • Throw-away or Exploratory prototyping
      • practical implementation of the system.
      • help to discover requirement problems.
    • Incremental prototyping
      • used to build the final product as a separate prototypes.
  • 15. Prototyping Objectives
    • To deliver a working system to end-users. The development starts with those requirements which are best understood .
    • To validate or derive the system requirements.
      • The prototyping process starts with those requirements which are poorly understood .
    • To merge the separate prototypes in the overall design.
  • 16. Prototyping Benefits
    • Misunderstandings between software users and developers are exposed.
    • Missing services may be detected and confusing services may be identified.
    • A working system is available early in the process.
    • The prototype may serve as a basis for deriving a system specification.
    • The system can support user training and system testing .
  • 17. Uses of System Prototypes
    • help customers and developers understand the requirements for the system.
      • Requirements elicitation
        • to see how the system supports their work.
      • Requirements validation
        • to reveal errors and omissions in the requirements.
    • a risk reduction activity which reduces requirements risks.
  • 18. Dimensions of Prototyping
    • Executibility
      • whether it will be run able or not
    • Maturation
      • improvement will be there or not
    • Representation
      • level of fidelity
    • Scope
      • limitations of functionality
  • 19. What is a Use case?
    • A sequence of actions that the system performs that yields an observable result of value to an actor.
    • A standard way of capturing, exploring and documenting what a system should do (the requirements of the system).
    • represents a series of interactions between an outside entity and the system, which ends by providing business value.
    • A collection of related success and failure scenarios that describe actors using a system to support a goal .
    • Use case are Written stories.
  • 20. Use Case-Place Local Call
    • Basic Flow
    • The use case starts when the caller lifts the receiver.
    • The caller enters the number to be called.
    • The system connects to caller’s phone to the requested device.
    • The call is mode.
    • The connection is terminated.
    • The detail of the call are recorded.
  • 21. Use-Case Diagram
  • 22. Methodology - Process
    • Define system boundary
      • What problems are solved
      • Who are the stakeholders
      • Client’s Organization main goals
    • Organize the team
    • Find Actors
    • Find Use Cases
    • Organize the Model
    • Prioritize Use Cases
    • Describe Use Cases
    • Verify and Validate
  • 23. Use Cases benefits
    • Promote customer involvement
    • Help manage complexity
      • Layers
      • Focus on real user needs
    • Groundwork for user manual, test cases
    • Help us work in iterations
  • 24. Use cases are not everything
    • They do not describe:
        • user interfaces
        • performance goals
        • application architecture
        • non-functional requirements
    • Sometimes –an overkill
  • 25. Conclusion
    • For requirement gathering and to resolve the challenges we need a process that should be Ordered, Controlled, Understandable, Not too complicated, Not too demanding and Flexible.
  • 26.
    • Thanks…