Scribd
Upload
30 views

Requirement Engineering - Software Engineering Slides

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
30 views

Requirement Engineering - Software Engineering Slides

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
You are on page 1/ 13

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..

You might also like