Scribd
Upload
27 views13 pages

Software Requirements Engineering Guide

The document outlines the importance of requirements engineering in software development, emphasizing the need to define system features, properties, and constraints before building a system. It categorizes requirements into user and system requirements, and further divides them into business, functional, and non-functional requirements, along with various types such as domain and inverse requirements. The requirements engineering process consists of seven tasks, including inception, elicitation, and validation, aimed at ensuring clear and structured system design to save time and costs.

Uploaded by

f223192
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
27 views13 pages

Software Requirements Engineering Guide

The document outlines the importance of requirements engineering in software development, emphasizing the need to define system features, properties, and constraints before building a system. It categorizes requirements into user and system requirements, and further divides them into business, functional, and non-functional requirements, along with various types such as domain and inverse requirements. The requirements engineering process consists of seven tasks, including inception, elicitation, and validation, aimed at ensuring clear and structured system design to save time and costs.

Uploaded by

f223192
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Software

Requirements Engineering
Introduction to Requirements:
 It is about deciding what a system should do before building it.

It describes system Features, properties (rules), and constraints or Limitations (like budget,
time, or security needs) on the development process.
Good requirements are essential as they provide the foundation for all subsequent development
activities.

Types of Requirements:
1. User Requirements:
 General statements about what users want.
 Written in simple language so non-technical people can understand.

These are general statements, often in plain language, about what the system should do
for users and any limits it has. They can be broad or detailed.

2. System Requirements:
 Detailed description of how the system will work.
 Used by developers to build the system.

More detailed explanations of the system's functions, services, and limits. These are often
technical and specific.

Example: Mentcare System (A Hospital Software):


 User Requirement: Creates monthly reports on drug costs per clinic.
 System Requirement: Details exactly how to generate these reports, including timing and
format.

 Users: Patients, doctors, nurses, IT staff, receptionists.


 Each user has different needs from the system.

Levels of Requirements:
 Business Requirements – What the company wants to achieve.
 User Requirements – What users need from the system.
 Functional Requirements – What the system should do.
 Non-functional Requirements – How well the system should perform.

Functional vs. Non-Functional Requirements:


 Functional Requirements (What the system does):
o Example: A hospital system should allow doctors to view patient reports.
 Non-Functional Requirements (How the system works):
o Example: The system should load reports in less than 3 seconds.
Non-Functional Requirements Categories:

1. Product requirements – Usability, Efficiency, Reliability, Portability


2. Organizational requirements – Standards, Implementation, Delivery

3.. External requirements - Interoperability, Ethical considerations, Legislative (safety, privacy)


 Product Requirements:
{1. Usability requirements} focus on how easily users can understand the system and provide user
supportiveness.

{2. Efficiency requirements} emphasize fast execution, performance, and minimal space usage.

{3. Reliability requirements} ensure the system is available 24/7 without crashing.

{4. Portability requirements} highlight the system's ability to run on multiple platforms like macOS,
Windows, and others, making the software more flexible and accessible.}

--------------------------------------------------------------------------
1. Domain Requirements
 Industry-specific requirements that must be followed.

 Can be functional (features) or non-functional (rules, security, laws).

 Example: A hospital system must comply with medical record laws.

2. Inverse Requirements
 Define what the system must NOT do.

 Useful when users are unsure of exact needs.

 Example: A banking app must not store passwords in plain text.

3. Design & Implementation Constraints


 Design Constraints: Restrictions on system design. (e.g., Must work on Android & iOS)

 Implementation Constraints: Restrictions on tools/technologies. (e.g., Must use Java)

 Includes hardware limitations and legal rules.

4. Requirement Origin vs. Cost


 Fixing requirement issues gets more expensive over time.

 Early mistakes → Low cost, Later mistakes → High cost.

 Example: Missing a core feature in the requirement stage is cheap to fix, but costly if noticed
after deployment.

🚀 Conclusion: Clear requirements save time and money!


Requirements Engineering Tasks:
The requirements engineering process consists of seven interconnected tasks:
1. Inception – Understanding what the project is about.
2. Elicitation – Collecting requirements from users and stakeholders.
3. Elaboration – Making requirements more detailed.
4. Negotiation – Prioritizing requirements based on budget and time.
5. Specification – Writing everything clearly in a document.
6. Validation – Checking if requirements are correct.
7. Management – Keeping track of changes in requirements.
i) Collaborative Requirements Gathering:
 Meetings are conducted and attended by both software engineers, customers, and
other interested stakeholders
 The goal is to identify the problem, propose elements of the solution,
negotiate different approaches, and specify a preliminary set of solution
requirements

ii) Quality Function Deployment:


 This is a technique that translates the needs of the customer into technical requirements for
software
 It identifies three types of requirements:
 Normal requirements, Expected requirements, Exciting requirements.
3. Elaboration:
 Elaboration refines requirements, and Analysis Modeling transforms them
into structured, visual representations!
 Analysis modeling provides the techniques (diagrams, use cases, class
models) to visualize and document these refined requirements.

1. Goals of Analysis Modeling:


 First technical representation of the system.
 Helps understand and organize system requirements.
 Uses diagrams to simplify complex information.
 Differentiates essential details from implementation details.
 Ensures better tracking and evaluation of system components.

2. Analysis Rules of Thumb:


 Focus on business needs, not technical details.

3. Analysis Modeling Approaches:


1. Structured Analysis (Traditional)
o Separates data (what is stored) from processes (how data is used).
o Uses Data Flow Diagrams (DFDs) to show data movement.
2. Object-Oriented Analysis (Modern)
o Focuses on objects (classes) and their interactions.
o Uses UML diagrams like Class Diagrams, Use Case Diagrams.

4. Elements of the Analysis Model:


 Scenario-Based Modeling: Use cases, activity diagrams.
 Class-Based Modeling: Class diagrams, object collaboration.
 Flow-Oriented Modeling: Data Flow Diagrams, process flow.
 Behavioral Modeling: State diagrams, sequence diagrams.
🚀 Conclusion: Analysis modeling ensures clear, structured, and efficient system
design
4.. Negotiation Task:

Art of Negotiation:
• Recognize that it is not competition

• Map out a strategy

• Listen actively

• Focus on the other party’s interests

• Don’t let it get personal

• Be creative

• Be ready to commit
5..

Common questions

Powered by AI

Structured analysis models focus on separating data from processes using Data Flow Diagrams (DFDs) to represent how data is moved and processed. In contrast, object-oriented analysis models concentrate on objects (classes) and their interactions, often using UML diagrams like class diagrams and use case diagrams to represent the system structure and behavior comprehensively .

Separating data and processes in structured analysis enhances system design by simplifying the representation of data movement and how they are used, using Data Flow Diagrams (DFDs). This approach clarifies understanding of system functionality and helps identify any inefficiencies or redundancies in data handling, thus leading to a more streamlined and effective system design .

Not addressing inverse requirements can lead to significant security and functionality issues, as these requirements specify what a system must not do, such as storing passwords in plain text in a banking application. Missing these could result in vulnerabilities and could further lead to costly security breaches or system failures .

The principles of Quality Function Deployment (QFD) can enhance software development projects by systematically translating customer needs into technical requirements. By identifying normal, expected, and exciting requirements, QFD helps prioritize features that will boost customer satisfaction and ensure the developed software aligns closely with customer expectations and strategic goals .

Managing requirement changes poses challenges such as scope creep, project delays, and resource allocation issues. Effective solutions include implementing a robust change management process that involves impact analysis, stakeholder engagement, and continuous communication. Additionally, keeping detailed documentation and prioritizing changes based on impact and feasibility can mitigate these challenges .

Collaborative requirements gathering is crucial because it involves meetings with software engineers, customers, and stakeholders to identify problems, propose solutions, negotiate different approaches, and specify preliminary requirements. This collaboration ensures that all perspectives are considered, leading to a comprehensive requirements specification that meets user needs and aligns with business goals .

Elaboration refines requirements by detailing and clarifying them, which is crucial for analysis modeling. It transforms these detailed requirements into structured visual representations using diagrams like use cases and class models. This technical representation helps in understanding, organizing, and documenting system requirements comprehensively .

Non-functional requirements significantly impact the performance and maintenance of a software system by dictating how well the system performs its functions. For example, requirements for usability, reliability, and efficiency affect user experience and system responsiveness, while portability requirements influence the ease of deploying and maintaining the system across different platforms .

User requirements are general statements about what users want from the system, often expressed in simple language that non-technical stakeholders can understand. In contrast, system requirements provide a detailed description of how the system will work, including technical specifications and detailed functionalities needed for developers to build the system .

The negotiation task affects the requirements engineering process by prioritizing requirements based on constraints such as budget and time. This process involves active listening, focusing on interests of all parties, and avoiding personal conflicts. It ensures that the most critical requirements are addressed and agreed upon by stakeholders and developers, facilitating a smooth development process .

You might also like