SRS Slide


Published on

Detailed description slide show about SRS document used in Software development process.

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SRS Slide

  1. 1. Introduction to SRS <ul><li>What’s SRS? </li></ul><ul><ul><li>Software Requirement Specification </li></ul></ul><ul><li>What’s it for? </li></ul><ul><ul><li>Requirement elicitation (functional & nonfunctional) </li></ul></ul><ul><ul><li>Analysis </li></ul></ul><ul><li>Who are its users? </li></ul><ul><ul><li>The client, the users, the system analysts, the system designers… </li></ul></ul><ul><li>Where is the template? </li></ul><ul><ul><li>B&D Textbook page 126 </li></ul></ul>
  2. 2. What are to be written in SRS <ul><li>Introduction </li></ul><ul><ul><li>Purpose, scope, objectives, reference, … </li></ul></ul><ul><li>Current System </li></ul><ul><ul><li>Describe the current state of affairs </li></ul></ul><ul><li>Proposed System </li></ul><ul><ul><li>Overview </li></ul></ul><ul><ul><li>Functional requirements </li></ul></ul><ul><ul><li>Nonfunctional requirements </li></ul></ul><ul><ul><li>Pseudo requirements </li></ul></ul><ul><ul><li>System models (Scenarios, use cases, object model, dynamic models, user interface) </li></ul></ul><ul><li>Glossary </li></ul>
  3. 3. Example: Jazz Festival Website <ul><li>This website is to display a table of Jazz shows including show time, location and band name. Tourists can select whatever shows of interest, and upon request a customized list of favorite shows is created as a personal guide to the festival. </li></ul>
  4. 4. Functional requirements <ul><li>The system shall allow the tourists to access the full schedule of Jazz festival shows </li></ul><ul><li>The system shall allow the tourists to select their favorite shows and customize personalized schedules </li></ul><ul><li>The system shall maintain the schedule data </li></ul>
  5. 5. Identifying nonfunctional requirements <ul><li>User interface and human factors </li></ul><ul><ul><li>What kind of interface? A web-based interface </li></ul></ul><ul><ul><li>What’s the level of expertise of the users? The tourists are assumed to have basic web access knowledge </li></ul></ul><ul><li>Documentation </li></ul><ul><ul><li>What level and kind of document? As required in the textbook: SRS, DD, TD </li></ul></ul><ul><li>Hardware considerations </li></ul><ul><ul><li>Hardware requirement? PC with Internet access </li></ul></ul><ul><li>Performance characteristics </li></ul><ul><ul><li>How responsive? Work load? </li></ul></ul>
  6. 6. Nonfunctional requirements -- cont. <ul><li>Error handling and extreme conditions </li></ul><ul><ul><li>How to handle exceptions? Which exceptions? </li></ul></ul><ul><li>Quality issues </li></ul><ul><ul><li>Reliability/availability/robustness? </li></ul></ul><ul><li>System modifications </li></ul><ul><ul><li>Any future changes? </li></ul></ul><ul><li>Physical environment </li></ul><ul><ul><li>Where will the system be deployed? </li></ul></ul><ul><li>Security issues </li></ul><ul><ul><li>What kind of security? To what level? </li></ul></ul><ul><li>Resource issues </li></ul><ul><ul><li>Any constraints on the resources consumed? </li></ul></ul>
  7. 7. Identifying actors <ul><li>Actors represent external entities that interact with the system </li></ul><ul><li>Who are supported by the system to perform their work? </li></ul><ul><li>Who execute the system’s main functions? </li></ul><ul><ul><li>The tourists </li></ul></ul><ul><li>Who perform secondary functions (maintenance & administration)? </li></ul><ul><ul><li>The maintainer </li></ul></ul><ul><li>Will the system interact with external systems </li></ul><ul><ul><li>Database/File </li></ul></ul>
  8. 8. Identifying scenarios <ul><li>A scenario is a concrete, focused, informal description of a single feature of the system from the viewpoint of a single actor </li></ul><ul><li>What are the tasks to perform? </li></ul><ul><li>What information accessed? Who creates that data? </li></ul><ul><li>… </li></ul>
  9. 9. Scenario – cont. <ul><li>Scenario name AccessFullSchedule </li></ul><ul><li>Participating actor Jane: Tourist </li></ul><ul><li>Flow of events 1. Jane opens IE and enters the address of the Jazz Festival website </li></ul><ul><li>2. The System presents a welcome page </li></ul><ul><li>3. Jane requests to view the full schedule </li></ul><ul><li>4. The System retrieves a full list of show from DB </li></ul><ul><li>5. The System presents a full show schedule </li></ul>
  10. 10. AccessFullSchedule Scenario in sequence diagram
  11. 11. CustomizePersonalSchedule Scenario in Sequence Diagram
  12. 12. Identifying use cases <ul><li>A use case specifies all possible scenarios for a given piece of functionality. </li></ul>
  13. 13. Use case –cont. <ul><li>Use case name AccessFullSchedule </li></ul><ul><li>Participating actor Initiated by the Tourist </li></ul><ul><li>Entry condition 1. The Tourist opens web browser and types the address of the Jazz Festival website </li></ul><ul><li>Flow of events 2. The System presents a welcome page </li></ul><ul><li>3. The Tourist requests to view the full schedule </li></ul><ul><li>4. The System retrieves information of show from DB </li></ul><ul><li>Exit condition 5. The System presents a full show schedule </li></ul>
  14. 14. Use case – cont. 2 <ul><li>Use case name CustomizePersonalSchedule </li></ul><ul><li>Participating actor Initiated by the T ourist </li></ul><ul><li>Entry condition 1. A full show schedule is displayed </li></ul><ul><li>Flow of events 2. The Tourist selects a favorite show </li></ul><ul><li>3. The Tourist repeats steps 2~3 </li></ul><ul><li>4. The Tourist requests to view the personal schedule </li></ul><ul><li>Exit condition 5. The System presents the personalized schedule </li></ul>
  15. 15. From Use Cases to Objects <ul><li>Identifying entity objects </li></ul><ul><ul><li>Terms that developers or users need to clarify to understand the use case </li></ul></ul><ul><ul><li>Recurring nouns in the use cases </li></ul></ul><ul><li>Identifying boundary objects </li></ul><ul><ul><li>The system interface with the actors (WelcomePage, Schedule) </li></ul></ul><ul><li>Identifying control objects </li></ul><ul><ul><li>Coordinates boundary and entity objects (WebServer) </li></ul></ul>
  16. 16. Class Diagram
  17. 17. Dynamic Model (state chart for the use cases)
  18. 18. Role of Diagrams <ul><li>Diagram information + text information covers what you w ant to represent in a document. </li></ul><ul><li>How much detail should a diagram reach? </li></ul><ul><ul><li>The detail and context the reader want. </li></ul></ul><ul><ul><li>E.g. What should a class diagram provide in SRS? </li></ul></ul>