Software Requirements Engineering Methodologies

12,689 views

Published on

Published in: Education, Technology
1 Comment
8 Likes
Statistics
Notes
No Downloads
Views
Total views
12,689
On SlideShare
0
From Embeds
0
Number of Embeds
163
Actions
Shares
0
Downloads
343
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Software Requirements Engineering Methodologies

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

×