Is the SRS dead Do we really need

Is the SRS dead? Do we really need it? What is it that it does? Name: Scott Mac. Kay Date: 2/14/17

What is an SRS? The SRS has many names: Supplementary Solution Requirements Specification Software System Requirements Specification More? It is a voluminous word document that has been used in software (and hardware) development projects going back almost to dawn of computers Page 2

Today’s World Everyone has become more “Agile” these days The business value of every written document has been questioned Non-value added efforts are being eliminated Even “Waterfall” projects have been trying to get more lean Some Agile groups have stopped writing the SRS Some BAs have supported its retirement – who really liked writing it anyways? So… Is the SRS dead? Page 3

Is the SRS Really Needed? The most common projects we work on are usually about enhancing an existing application Adding new features Adjusting compatibility with newer browsers, operating system or devices More? These types of projects inherently rely mostly on user stories or use cases to convey their details Sayonara SRS, we don’t need you Page 4

Do We Ignore the Hints of Need? Ever notice that during an enhancement project there are occasional questions that are not addressed by use cases / user stories? What browsers is this supposed to work with? How are data validation errors supposed to be handled? Is there role based security? Is it color blindness compliant? What date format is used? What coding languages are allowed? Are we multi-language Unicode compliant? What are the SLAs for fail-over and recovery? What…. Someone must know. I’m certain we don’t need an SRS for all of this. Page 5

What if the product is to be built from scratch? Where do you document the requirements that don’t fit into a use case / user story? In the Business Requirements Document (BRD)? Bad idea – the BRD is for new business capabilities, not detailed product specifications - wrong stakeholders and wrong audience Yes, the BRD might say the new product must work with the newest devices and have fast responsiveness – but that is too little detail Ignore them? – not a good option On the wall in the development center? – better In One. Note? – better In an actual SRS? - BINGO Page 6

And, there are changes in the wind Service Level Agreements (SLAs) are becoming more important as products move to the cloud Products are deploying to wider variety of devices and using more methods of connection Usability to shave seconds off product usage are getting higher priority Consistent look & feel is becoming more important Battery life, performance speed, application storage space are becoming bigger sales discriminators – esp. the collateral effects Development is routinely being done remotely making detailed written communications more important The quantity of solution requirements is growing and still needs its home Page 7

Let’s explore what goes into an SRS The SRS addresses system-wide requirements for subjects like: Functionality Reliability Usability Performance Security Supportability Licensing This is also were we document compatibility requirements for: Environments Platforms Operating Systems Browsers And software requirements such as: Languages Coding Standards None of this information belongs in a user story / use case – if it is was, it would be repeated over and over again Page 8

Is an SRS it hard to write? Yes & No The BA will need to ask questions and talk to the <technical> stakeholders No one stakeholder will likely have all of the answers Some answers won’t come until more is know about the product and it’s architecture And the architecture might wait until more is known about the product requirements The answers will come if you have the right questions – and maybe a few requirements workshop sessions Page 9

Make it an easy reader! Insert Visual Models – they make the difference! Context Diagram Business Object Model Key State Diagrams Key Sequence or Workflow Diagrams Deployment Model Break sections up by topic Insert tables for list of requirements Use bullets often Use plain English, test script tone, and the fewest words (no verboseness) Define technical words & acronyms Be Lean! – only put in what is needed, not one word more Page 10

What actually goes into a SRS? Page 11

Start with an Overview Short description of the product – not the project What does it do? Why does it exist? High level feature sets? Target user sets (persona audiences)? Scope – what is part of product Not in Scope – what is not part of product High level components? Specific excludes? supporting applications? Context Diagram – where the product fits in the process workflow Its all about the product – not the project – no tasks, names or deadline dates Page 12

Add a Glossary Define acronyms Define technical words Help the next guy get up to speed fast by taking some time to build a good glossary Page 13

Do Use Cases / User Stories Belong in the SRS? I say no! - not even a list of titles Why? The total list is never complete, even when you think it is There can be 100 s of them – esp if lean or agile They get written over a long period of time – typically a few per sprint They change often enough to need their own revision record – imagine how big the change record would be if use cases were in the SRS! There can be multiple versions active to support multiple releases But do store them with the SRS Page 14

System Requirements come in two types A functional requirement is a requirement that defines specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements. I have never seen the need to create separate sections for these two types – they are self evident and can apply to every requirement set. Page 15

The Functional Requirements – General User Languages? left or right orientation? Multi-Time Zones? Multi-Currencies? Multi-Units of measure? Persistent personalization? Gamification? Does inputability speed matter? Table features - user controls like sorting, paging, column hide, etc? Rules for special fields? SSNs, ZIPs, Telephony, Email? Sales tax rules? Legal Constraints? SOX? Safety? Write each requirement as a testable statement Page 16

Functional Requirements – User Interface Accessibility? Title 508? Alternative text for voice transcription Shapes for Color Blindness Minimal Screen flicker for Epileptics Flesch-Kincaid Grade Level Score? Gunning Fog Index? Branding? Logos? Trademarks? Copyrights? Font Styles? Screen Layout? Rotation? Images? Icons? Favicon? Screen Gestures? Facial Recognitions? Biometrics? Links to load needed Plug-ins? Sometimes I will create a separate “UI Style Guide” Page 17

The Functional Requirements – Environment Power needed? Volts, Amps, Phases? Temperature? Max, Min? Humidity? Max, Min? Access Controls? Physical, Software? Fire Suppression? Water? Atmosphere Gases? Vibration Levels? Max? Space Envelope? These generally only come into play with Hardware Page 18

Hardware Requirements Data storage sizing? File types? Duration? 30 days, 90 days, years? User sizing? Peak loads? Reserved capacity? Which browsers? Versions? Which operating systems? Versions? Screen resolutions & sizes? Minimal hardware needed? RAM? Storage? Processor speed? Special hardware/software accessories needed? Audio needed? Page 19

Software Requirements Software languages? Coding Standards? Dependent applications? Event logs? Encryption? Garbage clean-up? Self-annealing? Page 20

Usability Gray out options based on permissions? Or hide? Error messaging? Pop-up? Embedded? Exclude input of wrong data? Or accept and reject? Deletions process? Warn first? Mark as deleted? Undo? How many steps back? Auto-save? Save on tab? Save on request? Tabbing order important? Minimal user moves/actions important? Right-click menus allowed? Search Wildcards? Misspelling Tolerance? Type-ahead? Tool tips? Audio warnings? Page 21

Reliability What is the level of reliability needed? 97. 5%, How much data loss can be tolerated? 24 98%. 99%, 99. 9% Uptime? hrs, 8 hrs, 6 hrs, 1 hr? Mean Time to Recover? Page 22

Performance System response times? Launch? Save of record? Deep search? Display of reports? Failover to back-up system? Shut-down? Speed under peak loading? Power draw? (battery life) CPU usage (drag on user’s hardware) Storage space growth (space used on user’s hardware) Page 23

Security Sign-in required? Password Rules? Time-out for inactivity? Password recovery? Database encryption? What algorithm? Source code protection? Data Privacy? Authentication? Access? Permissions? Security Logs? Page 24

Supportability How must the product be supported? Built-in help? On-line Help? Contextual? Call Center? Home service calls? Product exchange? Product returns? Event Logs? Product to send events logs? Upgrade process? Rollback process? System back-ups? Geographic diversity? System health monitoring? Built in tests? Page 25

Licensing Is this product licensed? Copyrighted? Trade marked? How is it licensed and sold? By release? By subscription? What are the terms and conditions? Does a user need to accept the terms? Accept every time? Annually? On Updates? How are product updates made? User must inquire? Notification to user? On sign-in? What about user moving to new hardware? License expiration lockout? Usage Monitoring? Page 26

Purchased Components Does the product include any purchased components? Who built it, what is it used for? Will any of those components need to be disclosed in the product’s license? Is there a follow-on or pass-through licensing fee? Page 27

Installation Download? Send CD? Self-Install needed? Self-Extractor needed? License Key? Registration? Pre-install checks? Repair of install? Interruption tolerance? Page 28

Upgrades Manual/Auto upgrade? Up sell an upgrade? Download? Request CD? Refactor User’s data? Backward Compatibility? Page 29

Uninstallation Clean-up all? Leave configuration? Automatic uninstall on expiration of license? Survey trigger? Page 30

How the SRS fits in & traces back to the BRD Requirements Business Requirements Document (BRD) – executive level list of desired new business capabilities Solution Requirements Specifications (SRS) – What each solution application must do Use Case (UC) /Use User. Case Story Use Case (UC) / User Story (US) –Use What a (UC) Case feature must / User Story (US) – What a (UC) Case feature must /Use User Story do (US) – What a feature must. User / Requirements User Story do (US) – What feature must a do (US) What a / Use–Case (UC) feature must do feature must User (US) – do. Story What doa feature must do Designs Architecture & Designs – Decisions on how the application will be built to meet the requirements Product Software Code Complex products may require multiple SRS’s – Plan for one SRS and Use Case / User Story Set per Application Page 31

Multiple SRSs? One SRS per application is the norm Often a system will be made up of many applications integrated together It’s still one SRS per application A system will have will be multiple SRS’s and user story / use case sets Page 32

Put Design Decisions in the SRS? Not the right place! Requirements Designs state the “what” state the “how” The architects and designers will explore the many ways for “how” to achieve the “what”, and narrow down to the one best way If done right, you can redesign the entire product and not need to change the requirements Just don’t do it! Keep Architecture & Design separate from your SRS Page 33

Retrospect Could you have defined these by user stories / use cases alone? Could they really have been put in your BRD? Would the order of defining these solution requirements impact your architecture? Would the incremental discovery and frequent changes of embedded use cases / user stories cause the illusion of frequent SRS churn? Would the SRS need to be changed because of downstream design decision changes? Have you seen new products fail or run over schedule/budget due to lack of solution requirements? Page 34

Conclusions BRDs contain the leaderships desired new capabilities – not the system specifications SRS’s contain the system specifications for the application Use Cases / User Stories stand alone – not in the SRS Architecture & Design stand alone – not in the SRS should be maintained over the life of the product: Records system changes over time – by product update release Use multiple versions if supporting multiple releases It is very valuable for starting a new product Even more valuable if the product is to be subcontracted or built remotely Page 35

00 Questions? Page 36