Scribd
Upload
5 views

Project Management Module 02

software analysis

Uploaded by

Vignesh TbF
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
5 views

Project Management Module 02

software analysis

Uploaded by

Vignesh TbF
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Module 02

Chapter 02 : Requirement Modelling Scenarios,


Information and Analysis Classes
Model Question Paper : https://vtu.ac.in/pdf/QP/21CS61.pdf

BCS501-Module-2.pdf

Requirements Analysis
1. Purpose:

Specifies the software's operational characteristics.

Indicates the software's interface with other system elements.

Establishes constraints that the software must meet.

2. Process:

Elaborates on basic requirements established during inception,


elicitation, and negotiation tasks.

Results in various types of models: scenario-based, data models, class-


oriented models, flow-oriented models, and behavioral models.

3. Objectives:

Describes what the customer requires.

Establishes a basis for software design.

Defines a set of requirements that can be validated once the software is


built.

Requirements Modeling
1. Types of Models:

Module 02 1
Scenario-based Models: Depict user interactions from the point of
view of various system "actors."

Data Models: Represent the information domain for the problem.

Class-oriented Models: Represent object-oriented classes (attributes


and operations) and their collaborations.

Flow-oriented Models: Represent functional elements and data


transformation.

Behavioral Models: Depict software behavior in response to external


events.

2. Purpose of Analysis Model:

Provides a description of the required informational, functional, and


behavioral domains.

Serves as a snapshot of requirements at any given time.

Provides information for software designers to create architectural,


interface, and component-level designs.

Allows developers and customers to assess quality once the software is


built.

3. Focus:

Emphasizes "what" rather than "how."

Covers user interaction, objects manipulated, functions performed,


behaviors exhibited, interfaces defined, and constraints applied.

Analysis Rules of Thumb


4. Focus:

Should be on requirements visible within the problem or business


domain.

High level of abstraction.

5. Value:

Each element should add to the overall understanding of software


requirements.

Module 02 2
Should provide insight into the information domain, function, and
behavior of the system.

6. Delay Consideration:

Infrastructure and nonfunctional models should be considered during


design, not analysis.

7. Coupling:

Minimize coupling throughout the system.

Represent relationships between classes and functions but avoid high


interconnectedness.

8. Stakeholder Value:

The model should provide value to all stakeholders.

9. Simplicity:

Keep the model simple.

Avoid additional diagrams if they add no new information.

Use simple notational forms when possible.

Domain Analysis
1. Purpose:

Looks at the domain in which the application resides, not a specific


application.

Identifies common problem-solving elements applicable to all


applications within the domain.

2. Goal:

To find or create analysis classes and/or analysis patterns that are


broadly applicable for reuse.

Requirements Modeling Approaches


1. Structured Analysis:

Considers data and processes that transform the data as separate


entities.

Models data objects to define their attributes and relationships.

Module 02 3
2. Object-Oriented Analysis:

Focuses on defining classes and their collaborations to effect customer


requirements.

UML and the Unified Process are predominantly object-oriented.

3. Elements of Requirements Model:

Scenario-based Elements: Depict user interactions and the sequence


of activities.

Class-based Elements: Model objects, operations, relationships, and


collaborations.

Behavioral Elements: Depict how external events change the state of


the system or classes.

Flow-oriented Elements: Represent the system as an information


transform, showing data object transformation.

By understanding these points, you should be well-prepared to tackle


questions related to requirements analysis and modeling in your engineering
exam. Good luck!

Module 02 4

You might also like