andrew@theinternet

Software Dev Process Lecture Notes - Part 1 Lesson 5 and Part 2 Lesson 1 - Requirements

Requirements Gathering

• Very difficult task. Business people don’t wanna.
• Brainstorming tasks. example requirement, user wants tool to find average length of sentences in an essay
  • good example questions would be
    1. What OSes should it run on?
    2. How will the user specify input?
• avoid implementation-specific questions
• avoid OS-specific code where possible (platform independent is better)
• Example questions from interview
  • How many students?
    • 40-45 per class, 3 classes
  • What kind of computers are students using?
    • Doesn’t know, probably several.
  • How tech savvy are the students?
    • Wide range
  • What are the students submitting?
    • Raw text files via email
  • What constitutes a word?
    • Only wants larger words, guesses 3 letters?
    • Need flexibility here
  • What do you consider a sentence?
    • Ends in period, exl point, etc.
    • Seems to be unsure, e.g. about commas counting
    • Need flexibility here
• Concludes CLI java-based tool with good documentation. Lots of little error messages to help less tech savvy students with CLI usage
  • Core metric is avg number of words per sentence
  • Configurability about threshold word length
  • Configurability about what counts as a sentence
  • Results are avg number of words per sentence
  • Help messages if tool used incorrectly

Assignment 3 Requirements

• must use vanilla Java 1.6 or later, no libraries
• must compile with javac, no options
• executable from command line
• user specifies file path
• user specifies delimiters with -d
• user specifies word length lower limit with -l
• output must be average sentence length in words, rounded to two decimal places **

Requirements Engineering

• What are software requirements?
  • A description of what a system has to do.
    • Functionalty and features
  • Represented formally as text / shall statements
  • Represented non-textually as user stories or diagrams, etc.
• What is requirements engineering?
  • Working with stakeholders to elicit their requirements for the system
  • Analyzing those requirements to understand tradeoffs
  • Specification
  • Validation
  • Requirements management
    • Change management, feature adds, etc.
• Why is it important?
  • Failed projects if you screw this up.
  • If you don’t understand requirements, you’re going to build the wrong system
  • Need to ask all the right stakeholders.
  • Gets the project off on the right foot.
• The process of establishing the services that the customer requires of the system, and the constraints under which the system operates
• Focus on what the system needs to do, not how it will do so
• Software intensive system = softare + hardware + context
• Software quality is not just a function of the software, but of the combination of the software and its purpose.
  • Software can be of low quality not only because it doesn’t work well, but also because it does not fulfill its needed purpose.
• Completeness and Pertinence
  • Very difficult to gain a complete picture of the purpose of the softare. Often incomplete requirements are gathered
  • Pertinance = relevance. Often include unneeded functionality. Can also rake in conflicting requirements

Best Practices

Typical bad practice

• Devs list off requirements, stakeholders review/edit/approve
• Often stakeholders don’t bother / can’t make time, so just skip to approving
• SOUND FAMILIAR?

How to avoid?

• RE is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the context in which it will be used. Hence, RE acts as the bridge between the real-world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies

• Requirements are:

• Functional and non-functional requirements
  • functional = well-defined, system shall do X
  • non-functional = system’s qualities e.g. security, re-usability, speed, etc. squishier.
    • non-functional must be refined to be verifiable
• User vs System Requirements
  • user requirements are written for customers. often in natural language, no technical details
  • system requirements are written for developers, contain detailed functional and non-functional requirements. clearly and more rigorously specified
• Where do requirements come from?
  • Stakeholders - users want stuff
  • Application Domain - constraints applied here. E.G. regulations for banking software
  • Documentation
• Elicitation Problems
  • Thin spread of domain knowledge. Hard to run down all the people who know what all you need to know.
  • Knowledge is tacit. Stuff as actually done rarely matches exactly to what people describe.
  • Limited observability - hard to shadow enough to get clear requirements.
  • Bias. People may not want to, or be able to, accurately relay to you the way things actually work.
• Traditional techniques for requirement elicitation
  • Background reading - collecting information by reading existing documents. Especially good when not familiar with the org. Saves time spent interviewing actual people. However docs are often bad or out of date.
  • Hard data and samples
  • Interviews - this is very common. Structured or open-ended. Can collect rich set of information. However, require special skills to do well.
  • Surveys - very useful and allow casting a broader net. However, only good at capturing expected information of certain types.
  • Meetings - fundamental that clear agenda is set.
  • Other techniques
    • collaborative techniques - brainstorming,
    • social approaches,
    • ethnographic techniques (observe stakeholders in original environment)
    • cognitive techniques
• Modeling requirements
  • modeling enterprises
    • goals and objecticves
    • organizational structure
    • tasks and dependencies
    • agents, roles, intentionality
  • modeling information and behaviors
    • information structure
    • behavioral view
      • scenarios and use cases
      • state machine models
      • sequence diagrams
      • information flow
    • time/sequencing requirements
  • modeling system qualities (NFRS)
    • robustness, reliability, etc
  • after deciding what to model, must decide how you want to model it
    • there are tons of different models you can choose for each different thing you want to model. frequently they’re complementary, they can reinforce and aid each other
• For this course, we’ll use either natural language or UML diagrams for our requirements
  • goal modeling is very popular. start with main goal of system, then refine by decomposing into nested subgoals until you get to units of functionality
• Analyzing requirements
  • Verification
    • check whether they’re correct, complete, and pertinent, consistent, testable, etc.
  • Validation
    • assess whether collected requirements describe the system the stakeholders actually want
    • sometimes done by allowing stakeholders to interact with a prototype
  • Risk analysis
    • aims to identify and analyze main risks involved with development of the system being built
• Requirements prioritization
  • how to handle limited resources?
  • prioritize by classifying
    • mandatory
    • nice to have
    • superfluous

Recap

• 3 main steps
  • elicitation
  • modeling
  • analysis
• 4th kinda step - negotiation between stakeholders and devs
• Iterative process between all 4 stages until you are happy, then you stop.
• Requirements shoudl be simple, not compount
• Requirements should be testable
• Requirements should be organized, grouped, nested, prioritized

• Requirements should be numbered (for traceability)

• Software requirement specification (SRS) (document)
  • way to communicate requirements to others - common ground between analysts and stakeholders
  • different projects require different SRS
  • For this class we’ll use modified version of the IEEE standard SRS document