0% found this document useful (0 votes)
58 views

CS510 Software Requirements and Specification

Requirement Engineering (RE) is an important process that involves systematically gathering and defining what a software system needs to do from stakeholders. RE is critical because many software projects fail due to not getting requirements right, with 56% of errors coming from this stage. The RE process includes key activities like requirements elicitation, analysis, validation, and management to determine functional and non-functional requirements as well as constraints. Requirements should meet characteristics like being feasible, unambiguous, verifiable and traceable to user needs.

Uploaded by

noneuseemail1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
58 views

CS510 Software Requirements and Specification

Requirement Engineering (RE) is an important process that involves systematically gathering and defining what a software system needs to do from stakeholders. RE is critical because many software projects fail due to not getting requirements right, with 56% of errors coming from this stage. The RE process includes key activities like requirements elicitation, analysis, validation, and management to determine functional and non-functional requirements as well as constraints. Requirements should meet characteristics like being feasible, unambiguous, verifiable and traceable to user needs.

Uploaded by

noneuseemail1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Week 1

Q1. What is a Requirement and needed?


Ans. A requirement is something needed or wanted. It's like a rule or condition the
system must follow, that's really important for the system, as per IEEE. Requirements
are needed because they are the foundation for creating all software.

Q2. What challenges are associated with requirements?


Ans. Dealing with requirements is challenging because it requires people to interact,
and it can't be automated.

Q3. Why is it challenging to understand requirements?


Ans. Understanding requirements is hard because visualizing a future system is difficult,
the capabilities of the future system are not clear, and requirements change over time.

Q4. What is Requirement Engineering?


Ans. Requirement Engineering, starting in 1993, is a process to systematically
determine what a software product needs. It involves the development and use of
effective technology to gather, define, and analyze requirements from stakeholders
(clients/users) that a software system must perform. This was highlighted by the first
international meeting on RE in the same year.
Q5. Why is Requirement Engineering (RE) important?
Ans. Requirement Engineering is important because many software projects fail (74%
according to the CHAOS Report in 2000). 56% of software errors come from not getting
the requirements right. Deciding what exactly to build in a software system is the
hardest part. If we don't do this part well, it can really mess up the whole system, and
it's also tough to fix later. The importance of RE is highlighted by issues like complex
software, changing user needs, outsourcing projects, high costs of fixing mistakes, and
reasons for project failure.

Week 2

Q6. How to judge good and bad requirements?


Ans. 1. There are several criteria needed to meet good requirements.
2. Usually overlooked in requirement process
3. An excellent source to measure projects quality and progress.
4. Characteristics of requirements vs. Characteristics of Requirement
Specification.

Q7. Key characteristics of good requirements


Feasible: Realistic within time and budget.
Valid :It should make sense for the project.
Unambiguous: Clear and easy to understand.
Verifiable: Can be checked if done right.
Modifiable: Can be changed if needed.
Consistent : Match each other and project goals.
Complete: Cover all needed details.
Traceable : Link back to user needs.

Week 3

Q8. Kinds of Software Requirements (IMP)


1. Functional Requirements:
● Describe what the system does.
● Include the functionality of the system.
● Should be clear and consistent.
● Example: Users can search the whole patient database or choose a
subset.

2. Non-functional Requirements (NFR):


● Focus on quality factors, design criteria, and metrics.
● Define how the system should be.
● Cover aspects like timing, performance, security, etc.
● Often more critical than functional requirements.

3. Domain Requirements:
● Come from the application domain and reflect its characteristics.
● Can be functional or non-functional.
● Example: Most banks don't allow over-drawing, but some accounts may
allow it.

4. Inverse Requirements:
● Explain what the system should not do.
● Convenient way to express needs.
● Example: The system shouldn't use red color when asking for user input.

5. Design and Implementation Constraints:


● Development guidelines for designers.
● Can limit design and implementation options.
● Example: The system must be developed using Microsoft Dot Net or
open-source tools on Linux.

Q9. What is the process?


Ans: A process is an organized set of activities, which transforms inputs to outputs.
Processes document the steps in solving a certain problem

Q10. Why process?


Ans: They allow knowledge to be reused. Processes are important for handling
complicated things in the real world.

Q11. Software Processes


Ans: Software engineering, has many processes.These processes help in performing
different software engineering activities in an organized manner

Examples
● Software engineering development process (SDLC)
● Requirements engineering process
● Design process
● Quality assurance process

Q12. What is the RE process?


Ans: The steps in creating the system requirements are all together known as the "RE
process" or "requirements engineering process."

Q13. Which process to be used?


Ans:
● depends on:
● application domain
● the people involved and
● The organization developing the requirements.

Q14. RE Process
● Generic activities which is common to all processes
● Requirements elicitation
● Requirements analysis ◦ Requirements validation
● Requirements management.

You might also like