UPI Study › Courses › System Analysis and Design › Free lessons › Lesson 3.4 Free with a free account
How Requirements Are Gathered and Analyzed in the SDLC
System Analysis and Design · Chapter 3: Agile Methods and Rapid DevelopmentSection 3.4 · lesson 18 of 6910 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of System Analysis and Design.
Lesson complete
Earn the 3 college credits for System Analysis and Design
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Joint Application Development: Strengths and Limitations →← Agile vs. Traditional SDLC: A Side-by-Side ComparisonNext lesson: Joint Application Development: Strengths and Limitations →
In this lesson
5 requirement types, conflict resolution, prioritization, and the SRS.
- Distinguish business, user, functional, non-functional, and constraint requirements
- Place analysis and specification in the requirements engineering process
- Explain and resolve ambiguous and conflicting requirements
- Apply MoSCoW and Kano, and describe an IEEE 29148 SRS
Transcript
Everything said in the video, section by section (1,273 words). Read along, or search it.
Agile Methods and Rapid Development
Gathering and Analyzing Requirements
Every development approach, agile or traditional, runs on requirements. This section is about turning raw stakeholder input into requirements a team can actually build from. We will sort requirements into five types. We will see where analysis and specification sit in the wider process. We will look at how ambiguous and conflicting requirements get resolved. Then two prioritization techniques, MoSCoW and Kano. And finally, a standard structure for the requirements document itself.
Not All Requirements Do the Same Job
5 Types of Requirements
Not every statement labeled a requirement is doing the same job. Sorting them into five types keeps a project from mixing a broad business goal, with a narrow technical rule. That mixing is one of the most common sources of confusion in a requirements document. A business requirement is a high-level goal the system supports. For example, reduce average order processing time by thirty percent. A user requirement is what a specific user role needs to do, in plain language. As a warehouse clerk, I need to scan a barcode to update inventory. A functional requirement is a specific behavior the system must perform. The system shall update the inventory count within two seconds of a barcode scan. A non-functional requirement is a quality attribute. It describes how well the system performs, rather than what it does. The system shall support five hundred concurrent users, with page loads under two seconds. And a constraint is a restriction on the solution itself. For example, the system must run on the organization's existing Windows Server infrastructure.
How the Types Connect
Why, What, and Exactly How
Look at how the first three types relate. The business requirement states why the project exists. The user requirement states what a person needs to accomplish. And the functional requirement states exactly what the system must do to make that possible. In our example, faster order processing is the why. Scanning a barcode to update inventory is what the clerk needs. And updating the count within two seconds of the scan is exactly what the system does. The structure is a tree, not a flat list. A single business goal typically produces several user requirements. And each user requirement typically produces one or more functional requirements underneath it.
Figure 3.2
The Requirements Engineering Process
Requirements engineering is usually described as five linked activities. Elicitation, analysis, specification, validation, and management. This section concentrates on the middle two. Analysis and specification. That is where raw input from stakeholders becomes a clear, organized set of requirements. Analysis sorts each item into one of the five types. It checks for overlap between statements. And it surfaces conflicts and ambiguity, before they get built into the system. Specification then records the analyzed requirements in a structured, unambiguous document. That is typically a software requirements specification. It gives design and implementation a single, agreed source to build from. Elicitation and validation are examined in depth elsewhere in the course.
2 Different Problems
Ambiguous vs. Conflicting
Analysis runs into two different kinds of problem, and it is worth keeping them apart. An ambiguous requirement can be read more than one way. So different readers reasonably reach different conclusions about what it means. A conflicting requirement is different. Two requirements are each clear on their own, but they cannot both be fully satisfied at the same time. Both are normal outcomes of working with multiple stakeholders. And analysis is exactly where they are expected to surface, and get resolved.
Resolving Them
4 Common Causes and Their Fixes
Here are four common causes, and how each is typically resolved. First, vague language. The system should be fast. The fix is to rewrite it as a measurable non-functional requirement. Pages load in under two seconds. Second, conflicting stakeholder priorities. Sales wants one-click checkout. Compliance wants a mandatory identity-verification step. The fix is to bring both stakeholders together, negotiate a scope decision, and document the trade-off. Third, overlapping or duplicate requirements, where two statements describe the same behavior in different words. The fix is to merge them into a single, consistently worded requirement. Fourth, a requirement that conflicts with a constraint. A functional requirement assumes cloud storage, but a constraint limits the system to on-premises infrastructure. The fix is to escalate to the sponsor, for a scope or constraint decision. In every case, the resolution comes from a facilitated discussion with the affected stakeholders. The outcome, and the reasoning behind it, is documented, never quietly decided by whoever wrote the requirement.
Prioritizing by Necessity
MoSCoW
Once conflicts are resolved, the project still has to decide what to build first, and what to leave out entirely. The first technique for that is MoSCoW. It sorts requirements by how necessary they are. Must have means the system is not viable without it. Should have means important, but not vital. Leaving it out is painful, but a workaround exists. Could have means desirable but not necessary. It goes in only if time and budget allow. And won't have, this time, means it is explicitly agreed to be out of scope for the current release. That last category matters more than it looks. Writing down what will not be built prevents arguments later.
Prioritizing by Satisfaction
The Kano Model
The Kano model asks a different question. Not whether a requirement is necessary, but how it affects user satisfaction, if it is present or absent. A basic requirement, sometimes called must-be, adds little satisfaction when present. It is simply expected. But its absence causes strong dissatisfaction. A performance requirement raises satisfaction roughly in proportion to how well it is implemented. And its absence raises dissatisfaction in proportion too. An excitement requirement, or delighter, produces a disproportionate increase in satisfaction. Yet its absence causes no dissatisfaction at all, because nobody expected it. The two techniques are often used together. MoSCoW decides what must ship in this release. Kano shows which items will delight users, and which are merely expected. A requirement can even be a MoSCoW must have and a Kano basic at the same time. Necessary, but unnoticed unless it is missing.
IEEE 29148
Structuring the Software Requirements Specification
Finally, the document that holds all of this. A software requirements specification, or S R S, records a system's requirements in an organized, unambiguous form once analysis is complete. IEEE twenty-nine one forty-eight provides a widely used standard outline. The introduction covers purpose, scope, definitions and acronyms, and references. The overall description covers the product's perspective, major functions, user characteristics, constraints, and assumptions. The specific requirements section holds the functional, external interface, and non-functional requirements, each individually stated and numbered. Verification sets out the criteria that will confirm each requirement has been met. And the appendices hold supporting material, such as glossaries, analysis models, and reference diagrams. Notice that the five requirement types from earlier end up in the specific requirements section. Numbering each one lets it be referenced precisely, anywhere else in the project.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. A functional requirement is a specific behavior the system must perform. A non-functional requirement is a quality attribute, describing how well the system performs. A constraint is a restriction on the solution itself. MoSCoW prioritizes by necessity: must, should, could, and won't this time. The Kano model prioritizes by effect on satisfaction: basic, performance, and excitement. And an S R S is a software requirements specification, with IEEE twenty-nine one forty-eight giving its standard outline.
Key Takeaways
What to Carry Forward
To pull this together. Requirements fall into five types: business, user, functional, non-functional, and constraint. Analysis and specification turn raw stakeholder input into an organized, unambiguous set of requirements. They sit between elicitation and validation, in the wider process. Ambiguous requirements can be read more than one way. Conflicting requirements are each clear, but cannot both be fully satisfied. MoSCoW prioritizes by necessity, and Kano by effect on user satisfaction. The two are often used together. And an S R S built on IEEE twenty-nine one forty-eight gives requirements a standard, predictable structure across projects.
About System Analysis and Design at UPI Study
System Analysis and Design (Computer Science 390) is a self-paced online course of 69 video lessons in 9 chapters, from the analyst's role and requirements to UML modeling, interface and database design, testing, maintenance and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take System Analysis and Design with UPI Study
Where the credit goes
Universities that work with NCCRS
System Analysis and Design carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About How Requirements Are Gathered and Analyzed in the SDLC
What are the different types of software requirements?
What is the difference between ambiguous and conflicting requirements?
How do the MoSCoW method and the Kano model prioritize requirements?
What is a software requirements specification (SRS)?
About the System Analysis and Design course
How many college credits is System Analysis and Design?
How much does System Analysis and Design cost and what is included?
Which universities accept UPI Study credits?
How long does System Analysis and Design take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in System Analysis and Design.
69 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →