Software Requirements Workshop Presentation

  • 1,344 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,344
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
60
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Software Requirements Process PMI Tools & Techniques Forum Ivars K. Lenss, PMP Ivars@Lenss.us
  • 2. What Is a Requirement?(1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective.(2) 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 documents.(3) A documented representation of a condition or capability as in (1) or (2) Source: IEEE Std 610.12-1990Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 3. What Is a Requirement?The IIBA built on the IEEE definition:A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective. [source: IIBA Business Analysis Body of Knowledge (IIBA, 2008]Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 4. What Does a Requirement Look Like?• A sentence (“The system shall…”)• A structured sentence (as in a business rule)• A structured text template• A table or spreadsheet (list of stakeholders)• A diagram (workflow)• A model (entity-relationship diagram and details)• A prototype• A graph• Any format that communicates[source: Seven Steps to Mastering Business Analysis, Barret, 2009] Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 5. How Requirements Work Requirements are not solutions Design translates requirements into solutions Many stakeholders mix requirements with their proposed solutions Requirements gathering is discovering the essence of the system Essence is the business reason of the work - what the work would be if there was no project Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 6. Raw Requirements A raw requirement is an environmental or customer requirement that has not been analyzed and formulated as a well-formed requirement. (IEEE Std 1233, 1998 Edition) Higher-level statements of the business goals, objectives, and success factors Often expressed in initiating documents Often vague and subjectively interpreted Can be intermingled with ideas and suggestions for potential designs Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 7. Example Requirement: “The traffic monitor running in the background shall provide status messages at regular intervals not less than every minute.” What are the status messages? How are they provided to the user? If displayed, how long are they displayed? What is the acceptable timing interval?Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 8. Well-Formed RequirementsA well-formed requirement is a statement of system functionality(a capability) that can be validated, and that must be possessedby a system to solve a customer objective, and is qualified bymeasurable conditions and bounded by constraints. (IEEE Std 1233, 1998 Edition) Abstract: Independent of its implementation Unambiguous: Interpreted in only one way Traceable: Associated with source Validateable: Fit criteriaIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 9. Example Requirement: “The traffic monitor running in the background shall provide status messages at regular intervals not less than every minute.”  The traffic monitor shall display status messages in a designated area of the user interface  The messages shall be updated every 60 seconds, plus or minus five seconds  Messages shall remain visible continuouslyIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 10. Requirements Classification Functional Requirements - Things the product must do - Action verbs – calculate, produce, inspect, publish Nonfunctional Requirements - Qualities the product must have - Look and feel, performance, security, regulatory Constraints - Boundaries and limits on the solution - Business constraints - Technical constraints - Glossary and naming conventions - Training, knowledge transfer Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 11. Examples Functional The rail system shall move people from San Francisco to Los Angeles Nonfunctional The rail system shall operate at an optimal cruise speed of 100 miles per hour Constraint The rail system shall operate at a maximum speed of 130 miles per hourIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 12. Software Requirements Approaches Traditional  Requirements specification produced before starting design and build Agile  Developers and architects do not have a requirements specification as a starting point  The requirements are somewhere (they separate the what from the how)  If you identify a requirement, record it Incremental  Combination of traditional and agile approachesIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 13. Why Document Requirements? People forget things Verbal communication is subjective People sometimes answer the same question differently if asked twice Writing something down forces a person to think about it more carefully than when they say it Having more eyes to review highlights ambiguity New people joining the project need to know requirements If it’s not in writing, it doesn’t exist Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 14. What are Software Requirements? PMI Tools & Techniques Forum Ivars K. Lenss, PMP
  • 15. What is a Software Requirement?Software requirements include 3 distinct levels Business Requirements  Why the project exists  Business objectives User requirements  What the user will be able to do with the product Functional requirements  Behaviors or operations under specific conditionsIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 16. What is a Software Requirement? Nonfunctional requirements  Properties or qualities that the solution must have (look & feel, usability, performance, operational,…) Technical constraints  Pose restrictions on acceptable solution options:  Predetermined language  Predetermined hardware  Restrictions on message sizes, software sizes, number and size of files, protocols, architecture standards, etc.Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 17. Software Requirements Players  Customer  User  SupplierIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 18. Software Requirements Levels SOFTWARE REQUIREMENTS BUSINESS BUSINESS USER FUNCTIONAL DESIGN BUILD ANALYSIS REQUIREMENTS REQUIREMENTS REQUIREMENTS CUSTOMER USER SUPPLIERIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 19. User Requirements Bridge the requirements of the business and the requirements of the software A user is anyone who is affected by the project  Includes people and external systems that interact directly  Includes people and external systems that receive system by-products (reports, decisions, questions) Software development provokes change in the behavior of users Business workflow often changes, along with policies, procedures, interactions between people When defining user requirements, users will be faced with decisions about how and where to change their workIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 20. Functional Requirements Describe software functionality that developers must build Sometimes called behavioral requirements Typically in the form of “shall” statementsIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 21. Software Requirements SpecificationBasic issues addressed in an SRS are: Functionality External interfaces Performance Non-functional requirements Constraints imposed on the solution [IEEE Standard]Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 22. Exercise PMI Tools & Techniques Forum March 4, 2009 Ivars Lenss, PMP
  • 23. Exercise You have been assigned a project to manage development of software for an ATM machine. Your customer provides you with some business requirements, a use case diagram and architecture diagram for the ATM machine. You are planning to meet with your stakeholders to discuss software requirements.Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 24. Use Case Diagram ATM START SESSION CANCEL TRANSACTION VIEW BALANCE WITHDRAW CASH BANK CUSTOMER TRANSFER MONEY MAKE DEPOSITIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 25. Architecture Diagram ADMINISTRATOR ACCESS INTERFACE MONEY STORAGE ATM UNIT HARDWARE ATM ACCESS DEPOSIT INTERFACE INTERFACE CUSTOMER ACCESS STORAGE ATM UNIT INTERFACE SOFTWARE BANK INTERFACE CAPTURE CUSTOMER CARD DATA DATA BASE REPOSITIORY ATM DEVICE INTERFACE HOSTCOMMUNICATION MODULE Ivars K. Lenss, BANK HOST PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009 SYSTEM
  • 26. Exercise Divide into groups Each group will make a list of questions to ask to define requirements for the ATM software Write any questions that you would need to ask of your software supplier, your users, or your customer to elicit requirements for your software specificationIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 27. What is a Software Requirement?Software requirements include 3 distinct levels Business Requirements  Why the project exists  Business objectives User requirements  What the user will be able to do with the product Functional requirements  Behaviors or operations under specific conditionsIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 28. Software Requirements Specification Software specifications may contain all of the functionality of the product or part of a larger system Larger systems will typically have an SRS stating the interfaces between the systems The interfaces place external performance and functionality requirements upon the software Avoid placing design requirements in an SRS Specify the problem, not the solution Specify the system, not the project Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 29. Software Requirements Attributes Stability Status Acceptance criteria [metric] Complexity [metric] Performance [metric] Urgency [metric] Business value [metric] Risk [metric]Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 30. Establishing Metrics Project Metrics – measurements associated with the project  Cost, effort, schedule, risk, resources, etc. Product Metrics – measurements associated with the product  Defects, performance, size, etc. Software requirements are a good place to choose appropriate product metricsIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 31. Some Useful Software Metrics Product size Estimated and actual duration Estimated and actual effort Work effort distribution Defects Requirements statusIvars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009
  • 32. Requirements Patterns PMI Tools & Techniques Forum Ivars K. Lenss, PMP
  • 33. Requirements Patterns Requirement patterns recur repeatedly across commercial systems Eight domains 1. Fundamental (things needed for any kind of system) 2. Information (information the systems needs) 3. Data Entity (divide data entities by characteristics) 4. User Function (inquiry, report, accessibility, interface) 5. Performance (how fast, how long, how big, how much) 6. Flexibility (ability to adapt to suit changing circumstances) 7. Access Control (user registration, authorization) 8. Commercial (pertaining to systems used to run a business)Ivars K. Lenss, PMP PMI Tools & Techniques Forum Ivars@Lenss.us March 4, 2009 Source: Software Reruirements Patterns, Withall, 2007
  • 34. Further Reading1. Wiegers, Karl E., Software Requirements , 2nd ed., Microsoft Press, 20032. Wiegers Karl, E., More about Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, 20063. Withall, Stephen, Software Requirement Patterns, Microsoft Press, 20074. Hass K., Wessels D., Brennan K., Getting It Right, Business Requirement Analysis Tools & Techniques, Management Concepts, 20085. IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications6. IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications7. IEEE Std 1074-2006, IEEE Standard for Developing a Software Project Life Cycle Process