Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software requirements

How can we collect, balance, agree on software requirements, and manage them across the IT product lifecycle. This presentation is an excerpt from the special training, which includes
- stakeholder management;
- user stories management;
- aligning and prioritizing business vs technical requirements;
- developing prototypes and wireframes;
- manage risks.

  • Be the first to comment

  • Be the first to like this

Software requirements

  1. 1. Development of the Software Requirements
  2. 2. Страница  2 www.specialist.ru Brief about the trainer: Danil Dintsis  Start-up consultant with successful portfolio  Ph. D. (twice) in System Analysis and Technical management (ISCED verified)  Portfolio manager and IT consultant, and a trainer for 15+ years with the following certifications: – PgMP®, PMP® – EXIN accredited trainer for ITIL®, MOF®, Cloud computing, Operation services and Analysis (OSA®)
  3. 3. Страница  3 www.specialist.ru Main sources for our training
  4. 4. Страница  4 www.specialist.ru Module 1  Introduction
  5. 5. Страница  5 www.specialist.ru Path from great idea to business. Review: http://www.slideshare.net/IAMCP_Mentoring/how-to-create-a-business-plan-44673629 Estimate our project Attract Investors Our idea is great! Clouds!
  6. 6. Страница  6 www.specialist.ru Define: What do we mean by “requirement”  A condition or capability needed by a customer/user to solve a problem or achieve an objective.  A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.  A documented representation of a condition or capability as in item 1 or 2.
  7. 7. Страница  7 www.specialist.ru Project management lifecycle phases
  8. 8. Страница  8 www.specialist.ru When do we collect requirements  Initiating phase  Planning phase  Executing phase  Knowledge area: Scope management  Processes: Planning Scope management, Requirements collection, Defining Scope, Change management.
  9. 9. Страница  9 www.specialist.ru Uncertainties  Product (What?)  Project (How?)
  10. 10. Страница  10 www.specialist.ru Requirements could be addressed to: - a product - development processes (a project); - implementation - support
  11. 11. Страница  11 www.specialist.ru Uncertainties in Agile approaches
  12. 12. Страница  12 www.specialist.ru Uncertainties in Waterfall management
  13. 13. Страница  13 www.specialist.ru A Requirement Lifecycle 1 Elicitation 2 Analysis 3 Specification 4 Validation 5 Management
  14. 14. Страница  14 www.specialist.ru Module 2 Stakeholder Identification Collect requirements
  15. 15. Страница  15 www.specialist.ru Who are the stakeholders
  16. 16. Страница  16 www.specialist.ru ITIL® BRM vs Product Manager
  17. 17. Страница  17 www.specialist.ru BRM and IT Service Portfolio
  18. 18. Страница  18 www.specialist.ru Tools to collect requirements Laws, bylaws, procedures Focus groups, Charts Mission and vision Brainstorming & Delphi
  19. 19. Страница  19 www.specialist.ru How to brainstorm?  Define a problem  Gather experts  Collect ideas in a non-critical manner  Discuss and rank ideas  Select 3-4 alternatives
  20. 20. Страница  20 www.specialist.ru Kepner – Trego analysis Курс OSA ITIL® 2011 Ковалёв А.В. 2013 г. Define What is a problem? Describe Features •Which part needs improvement? •Why is it a problem? Location. • Where is a problem appears? Time When does a problem appear?? How often? Scale Is a problem important? How many job units are involved? Search for solutions Identify 2-3 solutions Test them Analyze Five phases of problem analysis:
  21. 21. Страница  21 www.specialist.ru The “Delphi” method  Define a problem  Define experts  Collect ideas in an anonymous manner  Discuss and rank ideas (in person or anonymous)  Select 3-4 alternatives
  22. 22. Страница  22 www.specialist.ru REVIEW: HTTP://WWW.SLIDESHARE.NET/IAMCP_MENTORING/STAKEHOLDER- MANAGEMENT-44672689 NAME Position ROLE in a PROJECT CONTACTS REQUIREMENTS EXPECTATIONS INFLUENCE ATTITUDE to a PROJECT Mr. X CEO Sponsor Decrease expenditures per client Innovation solution from world known vendor Increase brand value High Devoted to this project STAKEHOLDER REGISTER
  23. 23. Страница  23 www.specialist.ru Stakeholder Communication strategy  WIIFM – What In It For Me  SWOT  “Difficult” managers (as in CompTIA®): – Micromanager; – “Deaf” – “Aggressor”
  24. 24. Страница  24 www.specialist.ru Stakeholders’ Impact Analysis Matrix Influence on a project Negative with high impact. Involve, Exclude, Overwhelm Positive with high impact. Involve (Sponsor is in this quadrant) Administer Involve, Motivate Readiness to support ->
  25. 25. Страница  25 www.specialist.ru Example Stakeholder impact High Low Negative Stakeholders: often middle management Strategy: WIIFM, communicate in person Sponsor, key stakeholders Strategy: involve, include maximum demands and expectations Often: users, low-level staff. Strategy: Describe, educate, ignore (administrative efforts) Power users, team members Strategy: involve, delegate Project support Negative Positive
  26. 26. Страница  26 www.specialist.ru DO IT ON A REGULAR BASIS  Revise stakeholder register  Revise stakeholder attention and influence  Revise Stakeholder management plan  Ask sponsor for a help  Initiate change
  27. 27. Страница  27 www.specialist.ru Module 3 Classify and balance requirements
  28. 28. Страница  28 www.specialist.ru Requirement’s types  Functional – describe features of a product  Non-functional – describe constraints, technical, quality parameters (for example, availability, MTRS)  Emergent – are requirements, which describe integration facilities, constraints, which are critical to a whole system, not only for a certain product.  Business – describe business needs, assumptions and constraints  Technical – describe technical features, parameters, assumptions, and constraints
  29. 29. Страница  29 www.specialist.ru Assumptions and Constraints  Assumption is (80/20)  Constraint is  Types of constraints: – Financial – Technical – Compliance – Organizational
  30. 30. Страница  30 www.specialist.ru USER STORIES  As a USER ROLE  I want _________  In order to (so that) _____
  31. 31. Страница  31 www.specialist.ru INVEST principle  Independent  Negotiable  Valuable  Estimable  Small  Testable
  32. 32. Страница  32 www.specialist.ru EPIC user stories  EPIC is a large user story, which describes multiple features and benefits  An EPIC user story should be divided into several small ones  Example: As a director I want to control my staff
  33. 33. Страница  33 www.specialist.ru Ambigious words  All  Every  Forever  Last  Both  Other  Everybody  Total
  34. 34. Страница  34 www.specialist.ru User stories risks
  35. 35. Страница  35 www.specialist.ru Analyze user stories and bring them together
  36. 36. Страница  36 www.specialist.ru Story board. User/Workflow View
  37. 37. Страница  37 www.specialist.ru Story board. Screen view
  38. 38. Страница  38 www.specialist.ru Balancing requirements
  39. 39. Страница  39 www.specialist.ru Conceptual Design (as in IEEE 1016)  Conceptual design is a start point of software design at which the principles are established in: – Context viewpoint – Composition viewpoint – Logical viewpoint – Dependency viewpoint – Information viewpoint – Patterns use viewpoint – Interface viewpoint – Structure viewpoint – Interaction viewpoint
  40. 40. Страница  40 www.specialist.ru Feasibility analysis  Choose base platform/methods/vendor  Choose 2-3 alternative methods/vendors  Describe product/project scope more precisely
  41. 41. Страница  41 www.specialist.ru Functional analysis  The goal of a functional analysis is validating business vs technical requirements, constraints, integration opportunities.
  42. 42. Страница  42 www.specialist.ru Tasks in functional analysis  Which requirements should be implemented?  Are all of them necessary?  Can we unite requirements into sub-systems?  Prioritize requirements
  43. 43. Страница  43 www.specialist.ru MoSCoW prioritizing tool  Must  Should  Could  Would/Won’t
  44. 44. Страница  44 www.specialist.ru Align business and technical requirements ID Business Requirement Priority Source ID Technical Requirement Priority Source
  45. 45. Страница  45 www.specialist.ru Module 4 Develop requirements specification document
  46. 46. Страница  46 www.specialist.ru Waterfall and Agile approaches
  47. 47. Страница  47 www.specialist.ru Prototyping  A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.  Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed.
  48. 48. Страница  48 www.specialist.ru Prototypes type:  Fast or Rapid or Wireframe  Evolutional – Iterative development – SCRUM sprints  Extreme (for Web development only), three phases: – Static prototype (HTML) – Emulation – Integrated services
  49. 49. Страница  49 www.specialist.ru Wireframe  A very simple visual representation  Easy to discuss with users and between team members  A base ground for ideas
  50. 50. Страница  50 www.specialist.ru Advantages of prototyping  Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software.  Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications.[7] The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said.
  51. 51. Страница  51 www.specialist.ru Advantages of prototyping  Involve clients and users  Minimize threats  Improve user satisfaction  No waste time in development (lean)
  52. 52. Страница  52 www.specialist.ru Disadvantages of prototyping  Insufficient analysis  User confusion of prototype and finished system  Developer attachment to prototype  Excessive development time of the prototype  Expense of implementing prototyping
  53. 53. Страница  53 www.specialist.ru Critical overview. Tools  Iron triangle  Occam's razor
  54. 54. Страница  54 www.specialist.ru System and Software specifications  ISO/IEC 15288 (IEEE Std 15288™-2008), Systems and software engineering  Software Requirements Specification (SRS)  Related documents: – SPMP –Software project management Plan – SQAP – Software quality assurance plan – STD – Software testing documentation – SCMP – Software configuration management plan – SVP – Software verification plan
  55. 55. Страница  55 www.specialist.ru What is Software Requirements Specification (SRS)  A software specification (SRS) is a description of a software system to be developed. It lays out functional and non-functional requirements, and may include a set of use cases that describe user interactions that the software must provide.  SRS establishes the basis for an agreement between customers and contractors or suppliers.  SRS permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules. Software requirements specification prevents software projects from failure  SRS document enlists enough and necessary requirements that are required for the project development.  © Wikipedia. (https://en.wikipedia.org/wiki/Software_requirements_specification)
  56. 56. Страница  56 www.specialist.ru SRS Goals  Facilitating reviews  Describing the scope of work  Providing a reference to software designers  Providing a framework for testing primary and secondary use cases  Including features to customer requirements  Providing a platform for ongoing refinement via incomplete specs or questions
  57. 57. Страница  57 www.specialist.ru SRS Structure  Introduction – Purpose – Definitions – System overview – References  Overall description – Product perspective • System Interfaces • User Interfaces • Hardware interfaces • Software interfaces • Communication Interfaces • Memory Constraints – Design constraints • Operations • Site Adaptation Requirements – Product functions – User characteristics – Constraints, assumptions and dependencies  Specific requirements – External interface requirements – Functional requirements – Performance requirements – Logical database requirement – Software System attributes • Reliability • Availability • Security • Maintainability • Portability – others
  58. 58. Страница  58 www.specialist.ru Module 6 Risks. Resume.
  59. 59. Страница  59 www.specialist.ru What Is a Risk  Risk is a probable event, which impacts on a project or a product  In IT projects usually only negative risks (threats), which have negative impacts.  Common risks are called Anti-patterns
  60. 60. Страница  60 www.specialist.ru Common Project Risks (Threats) for Requirements  Analysis Paralysis  Groupthink  Cart before the horse  Vendor lock-in  Over-engineering
  61. 61. Страница  61 www.specialist.ru Common Individual Risks  Heroics  Gold plating  Silos
  62. 62. Страница  62 www.specialist.ru Challenges for requirements elicitation  'Problems of scope'. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.  Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.  Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility
  63. 63. Страница  63 www.specialist.ru Requirements quality can be improved through  Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.  Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise.  Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects.  Consistent use of templates. Producing a consistent set of models and templates to document the requirements.  Documenting dependencies. Documenting dependencies and interrelationships among requirements.  Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions.
  64. 64. Страница  64 www.specialist.ru Product Backlog  A Product backlog is a set of requirements (features) to be developed in a project  Features include: – User stories – Tasks – Knowledge tasks – Common risks and bugs
  65. 65. Страница  65 www.specialist.ru Product Backlog – by Features Feature 1 Feature 2 … Feature N Task1 Task3 Task2 Task5 Task 3 Task 6 …..
  66. 66. Страница  66 www.specialist.ru Product Backlog – by Priority Must Should Could Would Task2 Task 3 Task 4 Task 6 Task1 Task 5
  67. 67. Страница  67 www.specialist.ru  Contact us at:  dinzis@specialist.ru  consult@dintsis.org

×