1: Introduction to Software Development
2: Software Process Models
  2.5: Iterative Models
  2.6: Evolving the Iterative Model
  2.7: Risk: The Problem with Plan-Driven Models
  2.8: Agile Methodologies
  2.9: Agile Values and Principles
  2.10: eXtreme Programming (XP)
  2.11: XP Overview
  2.12: The Four Basic Activities
  2.13: Implementing XP: The 12 Practices
  2.14: Scrum
  2.15: Scrum Roles
  2.16: The Sprint
  2.17: Scrum Artifacts
  2.18: Sprint Flow
  2.19: Lean Software Development
  2.20: Kanban
  2.21: Kanban Board, WIP, and Flow
  2.22: Lead Time
3: Project Management Essentials
  3.1: Project Planning
  3.2: Project Organization
  3.3: Risk Analysis
  3.4: Resource Requirements
  3.5: Task Estimates
  3.6: Project Schedule
  3.7: Velocity
  3.8: Project Oversight
  3.9: Status Reviews and Presentations
  3.10: Defects
  3.11: The Retrospective
  3.12: Conclusion
4: Requirements
  4.1: What Types of Requirements Are We Talking About?
  4.2: User Requirements
  4.3: Domain Requirements
  4.4: Non-Functional Requirements
  4.5: Non-Requirements
  4.6: Requirements Gathering in a Plan-Driven Project
  4.7: But I Don't Like Writing!
  4.8: Outline of a Functional Specification
  4.9: Overview
  4.10: Disclaimer
  4.11: Author's Name
  4.12: Scenarios of Typical Usage
  4.13: Open Issues
  4.14: Design and New Feature Ideas
  4.15: One More Thing
  4.16: Requirements Gathering in an Agile Project
  4.17: The Three Cs
  4.18: Card
  4.19: Conversation
  4.20: Confirmation
  4.21: INVEST in Stories
  4.22: Independent
  4.23: Negotiable
  4.24: Valuable
  4.25: Estimable
  4.26: Small
  4.27: Testable
  4.28: Product Backlog
  4.29: SMART Tasks
  4.34: Time-Boxed
  4.36: Requirements Digging
  4.39: Problems of Understanding
  4.42: Analyzing the Requirements

Display:
Summaries
Questions
References

1: Introduction to Software Development

Summary

chapter 1 was a short chapter and it talk about the best way to develop software , you need to understand how to work with a team, so you need good communication skill. You also need understand how to work with customers and explain this to them. you need to use a process the everyone know so it would be easier to coordinate different code from different people in the same team. it also talks about understanding the right tools to use.

Questions

How to keep track of everyone's work of a project in software developemnt?

References

"Software Project Management" (Ahmed, 2015)

2: Software Process Models

Summary

Start of Chapter 2 Summary

this chapter talks about software process models and the four variables which are cost, time, quality, scope also called features. the chapter explain that you'll want to minimize each variables, and find the perfect spot for cost time quality and scope the make the best project. the book also explain that you need to focus on the features part of the project if your are the programmer because the cost and time your won't be able to control. late in the chapter the book talk about the waterfall process and that it's bad because it have you doing one thing then moving to the next its going linear, but that not how coding work people usually have to go back to some other part of the project to fix something or add something

Mid-Chapter 2 Summary

Iterative models are an software engineering model that takes a problem and creates a solution one step at a time. A team will take the known requirements and prioritize them based on the most important features to the customer. Each iteration of this process is viewed as a small project that brings constant small updates to a system. This model is implemented through evolutionary prototyping which prioritizes requirements as they are received. Hence allows for products to contain many new features as time progresses. A downside to evolutionary prototyping is the overly optimistic views about time, money, and progress. This model becomes sort of inefficient as more requirements are added. Although the downsides may weigh upon this implementation, it tends to work well with small, close teams. Although plan-driven models have worked well in the past, the main issue with them is risk. Risk can be in the form of schedule slips, project cancellation, etc. Agile Methodologies on the other hand recognize this and minimizes the risk. In the mid 90's a new lightweight-plan-driven model was created. This differed from the heavyweight-plan-driven because it required less documentation and few process controls for small to medium sized projects. The projects generated by the lightweight model tend to be used as smaller projects that provide services toward a bigger project. In early 2001 the Agile Manifesto was written. This was a description of values and 12 principles. The values will be lists at the bottom of the summary*. Another way to develop software is the eXtreme Programming(XP) method. It was created around 1995 and is described as a "lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software." The four fundamental ideas of this method is Heavy customer involvement, Continuous unit testing, Pair programming, and Short iteration cycles and frequent releases. The ideas around XP programming are what they say they are. There are a total of four main activities in XP: designing, coding, testing, and listening. Designing is creating structure that organizes the logic for the system. Coding is the main activity, and testing is very important for debugging. Listening involves gaining knowledge from your partner or the customer. XP is full of many standards, including its 12 practices(list below). The second agile methodology is Scrum, named after rugby, which means restarting the play after a rule is broken. Scrum is older than XP but the main difference is that scrum dev team typically consist of no more than 10 programmers. Similarly to other agile methods, Scrum puts an emphasis on small team efficacy and collective ownership.

Agile Values

Agile Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary way to measure progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective and then tunes and adjusts its behavior accordingly.

12 XP Practices

2.5: Iterative Models

Questions

Which of the following is not an advantage of iterative models?
  1. The customer is involved after the start of the development cycle.
  2. Mistakes by the programmers are accounted for.
  3. You know all the requirements for the final product at the start.

References

Decription of Iterative Models: p. 11 para. 2-

2.6: Evolving the Iterative Model

Questions

Which of the following isn't an upside of Evolutionary Prototyping?
  1. It makes scheduling easy and reliable.
  2. It works well with changing or ambiguous requirements.
  3. It makes it easier for the customer and management to track progress.
Which of the following isn't a downside of Evolutionary Prototyping?
  1. The code can be hard to maintain due to the frequently changing requirements.
  2. If too few requirements are implemented in each cycle, it can give an inaccurately high feeling of progress.
  3. The programmers are pushed into putting too much effort into making clean and bug-free code.
Evolutionary Prototyping is a recommended approach for new programmers.
  1. True
  2. False

References

Definition of Evolutionary Prototyping: p. 12 para. 1

2.7: Risk: The Problem with Plan-Driven Models

Questions

Which of the following is not an example of risk?
  1. Requirements Changing
  2. Schedule Slips
  3. False Feature Richness

References

Examples of Risk: p. 13 para. 1

2.8: Agile Methodologies

Questions

Who are Agile models meant for?
  1. Small teams making small projects
  2. Large teams making large projects
  3. Small teams making large projects
What does lightweight mean?

References

What lightweight means: p. 13 para. 4

2.9: Agile Values and Principles

Questions

Which of the following isn't a value from the Agile Manifesto?
  1. Individuals and interactions over processes and tools
  2. Clean, clear code over coding quickly.
  3. Customer collaboration over contract negotiation
The writers of the Agile Manifesto thought that the latter items in each value were still valuable.
  1. True
  2. False

References

Values of the Agile Manifesto: p. 14 list 1

Principles of the Agile Manifesto: p. 14 list 2

2.10: eXtreme Programming (XP)

Questions

What are the characteristics of eXtreme Programming?

References

Beck, K. Extreme Programming Explained: Embrace Change. (Boston, MA: Addison-Wesley, 2000.)

2.11: XP Overview

Questions

Which of the following isn't a fundamental idea of XP?
  1. Pair programming
  2. Continuous unit testing
  3. Work in progress

References

Four Fundamental Ideas of XP: p. 15 list 1

2.12: The Four Basic Activities

Questions

Which of the following activities isn't a part of XP?
  1. Designing
  2. Planning
  3. Listening

References

Four Activities of XP: p. 16 list 1

2.13: Implementing XP: The 12 Practices

Questions

Which of the following isn't a practice of XP?
  1. Iterating
  2. Metaphor
  3. Collective Ownership

References

12 Practice of XP: p. 16 list 2 & p. 17 list 1 & p. 18 list 1

2.14: Scrum

Questions

Scrum is:
  1. A management approach
  2. A programming approach
  3. A communication approach

2.15: Scrum Roles

Questions

User stories are:
  1. Feedback
  2. Input to a program
  3. Features
Which of the following isn't a role defined by Scrum?
  1. Project manager
  2. Product owner
  3. Scrum master
  4. Development team
The Scrum master makes the decisions.
  1. True
  2. False

References

The Three Roles in Scrum: p. 19 para. 1-3

2.16: The Sprint

Summary

A Sprint is an iteration of between one and four weeks. It's a fixed duration period and its output is determined by the amount of work done by the team in that period.

Questions

Sprints are defined by their limited:
  1. Scope
  2. Time
  3. Budget

References

The Sprint in Scrum: p. 19 para. 4

2.17: Scrum Artifacts

Summary

Two backlogs in Scrum.
1. Product Backlog: Created by the product owner. Is a list of all product requirements. Prioritised by the owner.
2. Sprint Backlog: Created by the dev. team. Breakdown of the product backlog into a prioritized list. Usually a visual board(physical or digital).
In an ongoing sprint, only the devs can add tasks to the sprint backlog. Outside entities can only add to the product backlog.

Questions

Which of the following isn't a backlog in Scrum?
  1. The sprint backlog
  2. The product backlog
  3. The story backlog
Which of the following isn't allowed in Scrum?
  1. The product owner adding to the sprint backlog between sprints
  2. The product owner adding to the sprint backlog during a sprint
  3. The development team adding to the sprint backlog during a sprint
The sprint backlog is visual.
  1. True
  2. False

References

The Scrum Backlogs: p. 9 para. 5

2.18: Sprint Flow

Summary

Planning phase before sprint starts. User stories are divided into prioritized groups. Fill up the time allotted with tasks. No task in a sprint is longer than one day of work. Breaking the tasks down makes it easier to estimate them.
Daily scrum meetings. No longer than 30 minutes. Help track progress.
After everything is done, a final scrum brings closure to the whole process. Requirements left in the product backlog is added to the next release.

2.19: Lean Software Development

Summary

Set of principles designed to improve productivity, quality and customer satisfaction.

Seven key principles of Poppendiecks:
1. Eliminate waste: Eliminate everything that doesn't add value to the product.
2. Build quality in: Two techniques used to improve quality; Pair programming and Test driven development (TDD). Constant feedback is another technique.
3. Create knowledge: The team must learn new things constantly.
4. Defer commitment: To make the big, irreversible decisions for later.
5. Deliver fast: Make it reasonably as fast as possible. Stick to the lean principles to optimize that.
6. Respect people: Pretty clear
7. Optimize the whole: Keep the bigger picture in mind.

2.20: Kanban

Summary

Derived from lean manufacturing. Three main ideas: work-in-progress, flow and lead time.

2.21: Kanban Board, WIP, and Flow

Summary

WIP and flow depicted visually on a Kanban board. Similar to a scrum task board.

2.22: Lead Time

Summary

It's the amount of time it takes for the team to move a task from one column to another in the kanban board. The date the task is started in the ToDo column is called entry date. The day it's done in called the done date.

3: Project Management Essentials

Chapter Summary

Project management is relevant for developers because if they ever work in a group, they'll either be managed (under a plan-driven system) or have partial responsibility for managing a project (under an Agile system). Project management is made up of three areas: project planning, project oversight, and the retrospective, which occur before, during, and after a project, respectively. The first step of project planning is deciding how the team will be organized, as well as what the process of making the project will be like and what each day of developing will look like. The next step is determining all that could go wrong and how to prevent what can be prevented and deal with the inevitable problems. The next step is figuring out what resources will be needed for the project. Next, the project is broken down into tasks small enough to predict the time needed for each, and that, along with considerations like certain tasks only being doable after other tasks and when developers will actually be able to code, is used to create a schedule for the project (though it's useful to include in the schedule some way to show how well everyone is able to follow the schedule). Project oversight includes meetings to discuss the current state of the project and any problems that anyone has run into. It also includes oversight from a manager to make sure that everything and everyone (including the manager themselves) is working smoothly, which includes providing positive motivation, listening to the developers, and separating the developers from distractions outside their roles. It may also include using a defect tracking system to keep track of defects and make sure they're dealt with. The retrospective is where the time spent on the project is examined to decide what did and didn't work as expected or desired and what should be done differently next time (as well as who will make sure things are done differently).

Summary

Understanding project management is required. Tasks involved: Project managers are responsible for The team manage the Agile project. They need to make to sure there is no delay in management decision-making. If there is a manager,

Questions

As developers, what tasks do we need to focus on the most? (Pg: 29) (T/F) In agile projects, the teammates are only responsible for managing their portion of the project. (Pg: 29)

3.1: Project Planning

Summary

For a plan-driven process model, a project plan is an actual document of how the project will be managed, written by the project manager.

A project plan has seven parts: An agile project is feature-based, mulitlayer and organized into iterations. The project is owned by the team.

Questions

(T/F) Project planning is done and fixed from the beginning. (Pg: 30)



What is a project plan? List different parts of it. (Pg: 30)

3.2: Project Organization

Summary

Three things for project organization are: These are important for brand new projects and inexperienced teams because it will help you to start the actual project work.

Since Agile team is small, it is easy to organize the project. The code, testings and expertise are all shared within the team. Being in an agile team will improve a lot of skills learning new things doing agile projects.

Agile projects are iterative, use short development cycles, and produce running code with more features at the end of each iteration. The team has daily meetings, integrations and shared or paired programming.

Questions

How are agile projects organized on a daily basis? (Pg: 31)

3.3: Risk Analysis

Summary

We need to think of possible factors that can go wrong and how we are going to prevent from happening. All the risks are needed to address and find a way to avoid the risk. We can remove some feature from a release, stop work on new features and do a bug hunt, negotiate new features into a future release, which is called mitigation. Then, we should have a plan to handle identifiable risks.

Questions

What are the general risks to look out for?

References

How are new requirements dealt with? (Pg: 32)

The new requirements are reviewed/examined by a change control board(CCB). They decide whether to add a new requirement to the list of things to be implemented.

What some good ways to deal with turnover? (Pg: 32)

If a developer leaves, the overload of work should be equally divided amongst everyone on the team. Principles like common code ownership and paired programming help divide that work efficiently.

3.4: Resource Requirements

Summary

(pg 33)

Resource Requirements are a simple part of management where you identify the whats, whens and wheres of the resources of the project. It includes Workstations, people, software, hardware and more.

3.5: Task Estimates

Summary

(pg 33)

The first steps towards a schedule is seeing what you'll be doing and figuring out how long each step will take. Task estimates are just that, estimates. It is impossible to know exactly how long a specific task will take and how accurate the developers prediction is largely based off of experience. The bigger the task the harder it is to know so it is better to breat down tasks that are estimated to take about a week or shorter. Then you can add them together and start doing larger estimates. "The estimation mantra is: size first, then effort and cost estimates, finally schedule."(pg 33) "Managers should never do development estimates. Even if a manager has been a developer in the past, unless they're deeply involved in the actual development work, they shouldn't be in the business of doing development estimates."(pg 34)

Questions

What is NOT a variable in the estimation mantra? (pg.33) What is the Delphi estimation technique? (short answer) (pg.33)

References

Delphi estimation technique: pg. 33 (last 2 paragraphs)
  1. The minimum amount of time it will take to complete
  2. The maximum amount of time it will take to complete
  3. The normal amount of time it will take to complete

3.6: Project Schedule

Summary

(pg 34-35)

Once you have the task estimates you can create a schedule. Important things to think about when making a cycle include the dependencies between tasks, your duty cycle, inclusion of sickdays and vacations, as well as the inability to schedule a developer to work on two tasks at once. It is also usedful to use project-scheduling software to make the schedule. It allows for greater organisation, especially for larger projects. Spolsky's Painless Schedule (pg 35) lists the following that should be in every schedule:

Questions

What is a duty cycle? (Short Answer) (pg.35)



How many items are in Spolsky's Painless schedule? (pg.35)

References

Project Schedule (pg. 34)

Once you have time estimates for an iteration, you can create a schedule. 4 items (below) state what you should consider while creating the schedule. Spolsky's Painless Schedule (pg. 35)

3.7: Velocity

Summary

(pg 35)

The Velocity of a task can also prove useful when creating a schedule. The velocity is defined as the estimated effort of a task, divided by the actual effort. If you overestimate your task, your velocity will be greater than one (your task took less time than you originally thought); if you underestimate, it will be less than one (the task took you longer than you originally thought). Ideally, velocity should be 1.0, but that hardly ever happens. Velocity can be used to give both the manager and the developers an idea of how accurate their predictions are.

Questions

What is the ideal velocity of a project? (pg.35) True or false, the ideal velocity is commonly achieved? # (pg.36)

References

Velocity (pgs. 35-36)

3.8: Project Oversight

Summary

Project oversight is the part of project management that happens during the programming portion of a project. It includes meetings to discuss the current architure, design and code of the project, as well as management of the schedule, developers, process, and the manager themselves. How it is handled is part of the agreed upon project process.

The manager also has to keep the developers happy and motivated, mainly by avoiding things like motivating through fear, treating the developers as resources, or allowing the developers to get caught up in distractions outside the realm of writing the program.

3.9: Status Reviews and Presentations

Summary

Status reviews are a part of every project, though larger projects have more formal ones. It is important to be honest and direct about your current progress and expected progress before the next review, as well as any problems you've run into. Avoid the temptation to just say what management wants to hear, because that leads to problems later.

When giving a presentation, design it around the knowledge level of the audience and the purpose of the presentation. When using PowerPoint, keep the presentations short and to the point, and keep the slides barebones and the bullet points brief and not full sentences.

3.10: Defects

Summary

Developers should try to minimize the amount of defects they introduce into their code. Despite this, defects will inevitably find their way into code, so developers should also try to find as many of the defects in code as possible before releasing it. The found defects can be referenced in a defect tracking system, which tracks current known defects and their severity. For example, one possible set of levels of severity is:
  1. Fatal: Crashes or non-functioning vital features
  2. Severe: Non-functioning major features
  3. Serious: Non-functioning major features with work-arounds
  4. Annoying: Defect or error that may annoy the user, but doesn't affect functionality
  5. New Feature Request: A request for a new feature (not a defect)
When fixing defects, developers should start with the highest severity ones. Developers should never release a product with Fatal or Severe defects in it, and in most cases should also remove Serious defects.

Questions

if you don't know what the defect is how would you make a defect tracking system if you don't know what your tracking?

References

Defect levels(pg 37)
  1. fatal: the program crashes
  2. severe: A major piece of the project don't work
  3. serious: A little piece of the project don't work but you can get around it
  4. Annoying: minor defect or error but not a big problem.
  5. new features: you have to add something new to your project.
the first 3 levels should be caught before the program is released

3.11: The Retrospective

Summary

Retrospectives are done after completing some goal, whether a project or major iteration under a plan-driven process, or an iteration, such as a sprint, under an agile process. During retrospectives, questions are asked about the developers' experience completing the goal, such as:
  1. What went right? Did things go as expected, and did we implement all the features the customer wanted?
  2. What went wrong? How many defects did we need to deal with, and how much overtime did we need to finish on time?
  3. What process issues came up? Which aspects of our planned process were problematic or infeasable in practice?
  4. What do we need to fix for next time? Given our answers to the previous questions, what do we need to fix in our process, work habits, or environment for the next project?
  5. Who's responsible for the fixes? Who should be in charge of making sure we follow our modified process?

Questions

1. what is the importance of the Retrospective part of the project?

References

The Retrospective(pg 38)
  1. what went right/wrong? did it go as plan
  2. how many defects did it take longer then expected.
  3. did you follow the process, if not why
  4. what can you/the team improve on for next project.
  5. who should fix the problems if there was any.

3.12: Conclusion

Summary

The developers should own the process and management should be supportive, listen to the developers (especially when it comes to schedules and estimates), and seperate the developers from distractions outside their roles.

4: Requirements (Pg: 39)

Chapter Summary

Before starting work on implementing a project, developers need to first work out the functional requirements for the project in order to be productive and make quality, useful code. Functional requirements are descriptions of what the end product must be able to do, from the users' perspective (meaning without any mention of the implementation). Functional requirements must be written in a natural language in order to make it easiest to imagine and describe possible features. Requirements include descriptions of what the users will see and do when using the product, mentions of the ways the product must function due to the areas it works in (income tax, wireless communication), descriptions of the more technical, non-obvious functions and qualities that the product must have to avoid the users having a frustrating or harmful experience, and pointed mentions of the things that are not currently considered requirements. There are different forms of functional requirements for plan-driven and agile projects. Plan-driven projects have functional specifications, which are written by one person (likely a manager), and include a brief description of the product's intended functionality and multiple scenarios describing various intended possible user experiences, along with excessively clear mention of whether the specification is final and uncertainties to bring up in the next meeting with the customer. Agile projects have user stories, which are descriptions of what the customer wants the product to be able to do or what they want to be able to do using the product, ideally along with mention of which types of users will want which things out of the product and why. There are three aspects to a user story. The first is writing on an object such as a note card or piece of paper containing a brief description of the user story and representing the need for further discussion of the user story. The second is said discussion, which should be a thorough, in-person discussion between all who have a stake or role in the successful creation of the product and should determine more of what the customer wants and the size and priority of the story, as well as whether the story should be broken into more manageable chunks. The third is what criteria the product should meet in order to have successfully implemented the user story, which will be converted into tests that can determine whether the user story has been followed successfully. User stories need to be clear enough that tests can determine that a story has been met, vague enough that developers can be creative and thoughtful in their implementation, small enough that the effort required to implement them can be estimated, not dependent on other stories being implemented first, and beneficial to the customer. Before implementation, user stories must be broken down into multiple implementation tasks, which must be very clear such that you can definitively tell when they're done, achievable with the developers and time allocated for them, and necessary to the implementation of the user story they're in service of. Getting the functional requirements from the customer can be difficult because they may say that the product should follow some current business policy that may change (and possibly necessitate a change to the product) in the future, they may describe unnecessary details of their ideal final product in place of the fundamentals of the product's purpose, they may not know exactly what they want from the product, the developers and customer may struggle to communicate in terms the other understands, the requirements will inevitably change over the course of the project, and the customer may bicker amongst themselves. Once the functional requirements have been determined, they need to be categorized, prioritized, and examined to determine if each is consistent with the intended function of the final product, necessary to implement the essential functionality of the product, testable, doable given the resources being worked with, and unambiguous.

Section Summary

As programmers, we are more inclined to just start writing code and fix the problems on the go. That practice is not very productive and can lead to a lot of trouble in the grand scheme of a project. To avoid such problems, a programmer needs to determine a set of requirements before they start working on the actual code.

Summary of Pages 47-51

chapter 4 is a interesting chapter it talked about requirements, and it was in three parts, requirements, requirement Digging, and analyzing the requirements. on pages 47-49 it listed out a few requirements for example measurable it being able to understand what needs to be done and be able to understand how long it would take to complete that program. also chapter 4 on pages 49-50 it talked about requirements digging or requirements elicitation, which is being able to get a user to tell you what they want. and being able to know that requirements hat customer don't know that want yet. one requirements elicitation is problems of scope which is being able to know what a customer want and make sure it can be done in the time limit required. the last part is analyzing the requirement which is taking the time to see if the requirements are really needed and is it consistent with the overall projects objective.

Questions

Which of the following is not a benefit of requirements? (pg. 39)
  1. Helps you make fewer errors
  2. Helps you implement the program
  3. Helps you come up with a good design
  4. Helps you listen to the users

4.1: What Types of Requirements Are We Talking About? (Pg: 39)

Summary

We care about functional requirements. They are the features that a user will experience when using the product. There are four types of those requirements:
  1. User Requirements
  2. Domain Requirements
  3. Non-functional Requirements
  4. Non-requirements

Questions

What are functional requirements? (pg. 39)
  1. The number of functions in the program
  2. The required efficiency level of the program
  3. The features users can see and use
Which of these is not a type of functional requirement? (pg. 39)
  1. Developer Requirements
  2. Domain Requirements
  3. User Requirements

References

Types of Functional Requirements: pg. 40-41

4.2: User Requirements (Pg: 40)

Summary

Always written in natural language; things that a user expects to see in their screen. This would include things like the descriptions of screen layouts, dialog boxes, and menus. Creating scenarios is helpful. Use visuals (pictures, mock-up webpages) to better understand and discuss the requirements.

Questions

Which of the following is not a trait of user requirements? (pg. 40)
  1. They include descriptions of screen layouts and dialog boxes
  2. They're nearly always expressed in natural language
  3. They always include a number of statistics

4.3: Domain Requirements (Pg: 40)

Summary

These are more like guidelines for the design of your product based on the industry you are working in. These are usually set universally and the programmer doesn't necessarily need to write them down. They just need to refer to them in order to remain in the set guidelines. Users would be not be concerned with these requirements as long as the user experience is not affected.

Questions

Developers must write down all the domain requirements for projects. (pg. 40)
  1. True
  2. False

4.4: Non-Functional Requirements (Pg: 40)

Summary

These are the constraints that the programmer has to work within. Some of the examples would include target platform specifications, timing constraints, performance requirements, memory usage requirements etc. They do affect the user experience but are not visible to the user.

Questions

Which of the following is not an example of a non-functional requirement? (pg. 40)
  1. Memory usage requirements
  2. Security requirements
  3. Screen layout requirements

4.5: Non-Requirements (Pg: 41)

Summary

There are certain things the final product will not be able to do. The programmer needs to communicate these things to the client so they can manage their expectations.

4.6: Requirements Gathering in a Plan-Driven Project (Pg: 41)

Summary

We are only concerned about the functional requirements during this phase of planning. Those requirements are just the things that the user will experience, written down in simple layman's terms.

Questions

Which of the following describes the internal implementation details of a program? (pg. 41)
  1. Domain specification
  2. Technical specification
  3. Functional specification
Agile methodologies include writing down functional requirements. (pg. 41)
  1. True
  2. False

4.7: But I Don't Like Writing! (Pg: 41)

Summary

The Sapir-Whorf linguistic relativity hypothesis, when roughly paraphrased, says that our ability to think and express those thoughts is limited by the language that we use. Using more expressive language can boost the effectiveness of figuring the requirements. That means it is highly recommended that the programmers write things down in regular, more expressive language before using the computer languages to implement the coding process.

Questions

Which of the following isn't a reason you should always write functional requirements in natural language? (pg. 41-42)
  1. Because it will make you better at talking to customers and coworkers
  2. Because the language you use determines what kinds of thoughts you are able to have
  3. To avoid getting bogged down in the syntactic and semantic details of a programming language before you need to

4.8: Outline of a Functional Specification (Pg: 42)

Summary

Different projects have different specifications. The elements of functional specifications are:
  1. Overview
  2. Disclaimer
  3. Author's name
  4. Scenarios of typical usage
  5. Open Issues

References

Outline of a Functional Specification: pg. 42-43

4.9: Overview (Pg: 42)

Summary

This is the executive summary of the product. It briefly explains what the program is supposed to do.

Questions

How long should the overview in a functional specification be? (pg. 42)
  1. 1-3 sentences
  2. 1-2 paragraphs
  3. 1 page

4.10: Disclaimer (Pg: 42)

Summary

Make sure to violently declare that things are not finalized in the planning phase and if somebody believes something is wrong/missing, it can be fixed using proper communication.

Questions

At some point the disclaimer should change to say that the specification is finished. (pg. 42)
  1. True
  2. False

4.11: Author's Name (Pg: 42 - 43)

Summary

It is usually either the Development Manager or the Project Manager, based on how the organization operates. There are pros and cons to both of them. Ideally, the author should be able to understand the technical aspects well enough to write proper specifications meanwhile also having good people skills to be able to get the stakeholders on board with everything.

Questions

Who should be responsible for the functional specification? (pg. 42)
  1. One person
  2. The development team
  3. A project manager

4.12: Scenarios of Typical Usage (Pg.43)

Summary

These are the requirements of the project. You can show a programs typical usage to get customers because you can present several scenarios of typical usage as part of the specifications.

Questions

Scenarios of Typical Usage are an effective way of identifying requirements because?:
  1. If you write the scenarios as if they're user stories, the customer is more likely to read them.
  2. Customers are more likely to understand what you're doing and come up with ideas for things you've missed or gotten wrong.
  3. It allows for the customer to see low level requirements.
  4. They help the developers identify which requirements they want.
  5. Scenarios do not help identify requirements.

4.13: Open Issues (Pg.43)

Summary

There will be a few unknown things during the write-up of the functional specification. Create an issue and leave it open as the project progresses. Each time the customer is met with, try to get the answers to these open issues.

Questions

The open issues section includes:
  1. unknowns from the user requirements
  2. unknowns from the functional specifications
  3. unknowns from the technical specifications

4.14: Design and New Feature Ideas (Pg. 43-44)

Summary

Project managers and developers create two different types of notes. These types of notes are technical notes containing design or coding ideas for developers. An example of these notes can consist of a backlog: A set of notes containing requirements that are to be implemented on the next release.

Questions

What are three positives of Backlogs?

4.15: One More Thing (pg.44)

Summary

Don't spend all of you're time obsessing about making sure every functional specification is correct. Chances are the customer will add additional requirements anyway. Also functional specifications are only considered complete after ship and release, so once again don't obsess.

Questions

When is the only time a functional specification is complete?

4.16: Requirements Gathering in an Agile Project (pg.44)

Summary

There is no functional specification in an agile development project. This is because developers of an agile team recognize that requirements will change over the course of a project and embrace that. There is no need to gather requirements because an agile development team contains the customer as part of the team. That way there is room for immediate feedback, and timely updates on requirements.

4.17: The Three Cs (pg.44)

Summary

A user story has 3 fundamental components: the card, the conversation, and the confirmation.

4.18: Card (pg.45)

Summary

A piece of paper, index card etc. Any physical thing in which the user story is written on. This acts as an invitation to a collaborative conversation about what the story really is and wants.

Questions

A card is usually a detailed story?:
  1. True
  2. False

4.19: Conversation (pg.45)

Summary

Takes place between important stakeholders in the project. This conversation essentially covers material that the owner really wants to see in the story. This can include revisions to the story, time estimates, and more details about the story.

Questions

The conversation about a user story takes place between all the important stakeholders in the project?:
  1. True
  2. False

4.20: Confirmation (pg.45)

Summary

The last component of the user story. The product owner provides this as the final form of acceptance criteria for the story. Typically very simple and written on the back of the card as bullet points.

Questions

What format are the acceptance criteria usually written in?:
  1. Paragraph
  2. Bullet list
  3. Ordered list
  4. Markdown

4.21: INVEST in Stories (pg.45)

Summary

The previous 3 components of a user story tell us about the system. The acronym INVEST refers to the quality of the story.

Questions

What does the acronym INVEST stand for?:

4.22: Independent (pg.45)

Summary

Each user story should be independent of each other. That way a single user story can be scheduled and implemented separately from any other user story. This can be important based on which agile process a team is using.

Questions

Stories should be dependent on each other?:
  1. True
  2. False

4.23: Negotiable (pg.46)

Summary

A good story has room for negotiation among the parties involved. This should leave the developer and owner room to create an unique and workable implementation.

Questions

The story is specific that reads like a contract?:
  1. True
  2. False

4.24: Valuable (pg.46)

Summary

A good user story must have some kind of value to the customer. It must describe a feature or service that will be implemented in the product before the iteration is complete. Also, if a teams user story is too long, they should separate them into two smaller stories to be implemented in two different iterations.

Questions

Should splitting stories be based on value to the customer or technology?:

4.25: Estimable (pg.46)

Summary

Estimation is apart of the negotiation on the conversation. User stories must be able to be estimated because the product owner needs to be able to assign a relative priority to the story. Stories should not be too long, if so they might be subject to story splitting for a future iteration.

Questions

How many person-hours ideally should a story be broken up into?:
  1. 2
  2. 8
  3. 16
  4. 20

4.26: Small (pg.46)

Summary

As stated a few times above, good user stories should be relatively small. This also helps increase the accuracy of the user story estimation. Rule of thumb: Should take no more than eight man-hours of work to complete.

Questions

Good user stories should be small?:
  1. True
  2. False

4.27: Testable (pg.46)

Summary

User stories must be testable. This relates back to the idea of traceability where you should be able to trace a feature back through previous iterations designs, and requirements. This will confirm if the user story is correctly implemented.

Questions

Who writes the acceptance criteria?
  1. The developers
  2. The stakeholders
  3. The development manager
  4. The product owner

4.28: Product Backlog

Summary

Questions

Project owner gets to decide the deadline and release date of the project. p.47

4.29: SMART Tasks

Questions

Describe Tasks. p.47

4.34: Time-Boxed

Questions

The goal of time-boxed is to: p.48
  1. finish within the iteration
  2. having fixed time schedule
  3. overestimate the velocity
  4. underestimate the velocity

4.36: Requirements Digging

Questions

An example of an actual requirement of a project is: p.48,49
  1. The system must let the user choose a loan term
  2. Loan terms must be between 6 months and 30 years
  3. Loan terms are of finite length but the length of the loan will vary by the type of loan.
  4. The user must be able to select a loan term using a drop-down list box.

4.39: Problems of Understanding

Questions

Two ways to overcome problems of understanding are: p.49

4.42: Analyzing the Requirements

Questions

3 steps of analyzing requirements are: p.51 Precise requirements also means they are testable requirements. p.51