1. Classical vs. Agile Requirements Development Svetlin Nakov Telerik Software Academy academy.telerik.com Senior Technical Trainer www.nakov.com

2. 1. Software Engineering Overview 2. Development Methodologies Overview 3. Software Requirements Overview  The Formal Approach: Specifications  The Agile Approach: User Stories  UI Prototyping 2

3. Requirements, Design, Construction, Testing, …

4. Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. Definition by IEEE 4

5.  Software engineering is:  An engineering discipline that provides knowledge, tools, and methods for:  Defining software requirements  Performing software design  Software construction  Software testing  Software deployment and maintenance tasks  Software project management 5

6.  Software development always includes the following activities (to some extent):  Requirements analysis  Design  Construction  Testing (sometimes)  These activities do not follow strictly one after another (depends on the methodology)!  Often overlap and interact Software Project Management 6

7. Waterfall, Scrum, Lean Development, Kanban, Extreme Programming

8.  A development methodology is a set of practices and procedures for organizing the software development process  A set of rules that developers have to follow  A set of conventions the organization decides to follow  A systematical, engineering approach for organizing and managing software projects 8

9.  Back in history  The "Waterfall" Process  Old-fashioned, not used today  Rational Unified Process (RUP)  Microsoft Solutions Framework (MSF)  Modern development methodologies  Agile development processes  Scrum, Kanban, Lean Development, Extreme Programming (XP), etc. 9

11.  The waterfall development process: SoftwareRequirementsSoftwareRequirements SoftwareDesignSoftwareDesign Implementation(Coding)Implementation(Coding) Verification(Testing)Verification(Testing) Operation(Maintenance)Operation(Maintenance) 11

13. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“ Manifesto for Agile 13

14.  Incremental  Working software over comprehensive documentation  Cooperation  Customer collaboration over contract negotiation  Straightforward  Individuals and interactions over processes and tools  Adaptive  Responding to change over following a plan 14

15. 15

16. Functional, Non-functional Requirements, SRS

17.  Software requirements define the functionality of the system  Answer the question "what?", not "how?"  Define constraints on the system  Two kinds of requirements  Functional requirements  Non-functional requirements 17

18.  Requirements analysis starts from a vision about the system  Customers don't know what they need!  Requirements come roughly and are specified and extended iteratively  The outcome might be the Software Requirements Specification (SRS)  Or more informal set of assets  Prototyping is often used, especially for the user interface (UI) 18

19.  The Software Requirements Specification (SRS) is a formal requirements document  It describes in details:  Functional requirements  Business processes  Actors and use-cases  Non-functional requirements  E.g. performance, scalability, constraints, etc. 19

20.  It is always hard to describe and document the requirements in comprehensive way  Good requirements save time and money  Requirements always change during the project!  Good software requirements specification reduces the changes  Prototypes significantly reduce changes  Agile methodologies are adaptive to changes 20

21. Live Demo

22. The Agile Principles in Requirements Process

23.  Requirements specifications are too heavy  Does not work well in dynamic projects that change their requirements every day  Agile development needs agile requirements  Split into small iterations  How to split the requirements?  Use simple, informal requirements description  User story: a small feature that brings some value to the end-user 23

24.  User story  User needs to accomplish something  Written informal (in words / images / sketches)  Looks like use-case but is different (less formal)  User stories have  Actor (who?)  Goal (what?, why?)  Other info  Owner, estimate, … 24

25. 25

26.  Card  A brief description of the feature  In "Actor – goal" format  Conversation  More details, emails, chats, images, etc.  Documents, examples, issues, etc.  Confirmation  Test scenarios for success and failure 26

27.  A well written User Story should follow the INVEST model  Independent  Negotiable  Valuable  Estimable  Small  Testable 27

28. Live Demo

29. Using UI Prototypes instead of Specification

30.  A software UI prototype is a prototype of the software functionality and user interface  Sketch of the UI matching the requirements  Empty pages / forms / dialogs / tables / buttons  Just to outline how the UI could look like  A software prototype could be:  Static (e.g. paper / whiteboard prototypes)  Live (link / button simulate system behavior)  Throw-away prototypes vs. usable prototypes 30

31.  Tools for UI prototyping  Paper, pen and your hand  The most universal prototyping tool  Balsamiq Studio – balsamiq.com balsamiq.com  Microsoft Expression SketchFlow  Part of MS Expression Studio  Pencil Project – pencil.evolus.vn pencil.evolus.vn  … and many more  The best UI prototyping tools are paid 31

32. Live Demo

33. Questions? http://academy.telerik.com