Introduction to

Requirement
Modeling
Requirement modeling is the process of translating user needs
and business goals into a clear and comprehensive set of
requirements. It's essential for developing software that meets
the needs of its users and aligns with the overall business
objectives.
Importance of Requirement Modeling
Requirement modeling provides a shared understanding of the project's scope and
goals. It serves as a foundation for all subsequent development activities. It helps
avoid costly rework and ensures that the final product meets the intended needs.

Clear Communication Reduced Risks

Requirement models facilitate clear By identifying potential issues early in the
communication between stakeholders, development cycle, requirement modeling
developers, and testers. Everyone helps minimize risks associated with
involved can understand the project's project delays, budget overruns, and poor-
requirements in the same way. quality software.

Improved Quality Enhanced Testability

Requirement modeling ensures that all Well-defined requirements make it easier
necessary features and functionalities are to create effective test cases and ensure
included in the software, contributing to a that the software meets the specified
higher-quality product. criteria.
Requirements
Modeling Techniques
There are many different tools that can be used for
Requirements Modeling, depending on the needs of the
project. Some of the most popular requirements modeling
tools include
Traceability Matrix is a document that establishes and Characteristics:
maintains a relationship between requirements and test RTM is created according to the organizational standards
cases. It provides a visual representation of how each and needs, but it generally includes requirement ID,
requirement is covered by one or more test cases. This baseline document reference number, bug ID, and test
matrix ensures that every requirement is tested and helps cases
identify any gaps in test coverage.
Advantages of Requirements
Traceability Matrix (RTM)

1. It ensures that all the requirements have been captured through the test
cases.
2. It helps in assuring the client that the product is developed as per their
requirements.
3. It simplifies the process of identifying any loopholes or missing feature
implementation.
4. It ensures complete test coverage; as a result, all individual modules and their
possible combinations have been tested.
5. It can keep track of the overall test execution progress and bugs logged.
6. It helps the team to keep track of the inclusion of all of the team members in
each cycle of the SDLC
Disadvantages of Requirements
Traceability Matrix (RTM)

1. Complexity and Overhead

Creating, updating, and maintaining an RTM demands meticulous attention to
detail and a significant investment of time and resources. This complexity not only
adds to the workload of project teams but also complicates the overall project
management process
2. Time-Consuming Updates
The need for frequent updates stands as a significant drawback of using an RTM,
consuming a disproportionate amount of time that could otherwise be directed
toward developmental tasks. Each alteration in project requirements, no matter
how minor, necessitates a corresponding update in the RTM, turning maintenance
into a continuous and often tedious process.
3. Limited Flexibility
The structured nature of an RTM often comes at the cost of flexibility, making it
challenging to adapt to changes and iterations common in dynamic project
environments. This rigidity can hinder responding to new insights, customer
feedback, or evolving market trends.
4. Risk of Information Overload
An RTM can quickly become an overwhelming repository of information, with the
dense accumulation of data leading to confusion rather than clarity.
Disadvantages of Requirements
Traceability Matrix (RTM)

5. Requires Rigorous Discipline

The success of an RTM is heavily dependent on the discipline of project team
members in consistently documenting and updating every change. This
requirement for meticulous attention to detail and strict adherence to processes
can be daunting and may lead to resistance or shortcuts.
6. Potential for Outdated Information
The dynamic nature of projects, especially in agile and fast-paced environments,
means that information can quickly become outdated. With its intricate web of
requirements and dependencies, the RTM is particularly vulnerable to this,
potentially leading to decisions based on obsolete data.
7. Dependency on Tool Proficiency
The effectiveness of an RTM is often contingent on the project team’s proficiency
with specific tools designed to manage these matrices. This reliance can create
barriers to entry for new team members and necessitates ongoing training.
8. High Initial Setup Cost
The upfront effort and resources required to establish an RTM are not
insignificant. Initial setup involves the selection and configuration of tools and the
comprehensive mapping of requirements, which can be particularly daunting for
large or complex projects.
Disadvantages of Requirements
Traceability Matrix (RTM)
9. Can Lead to False Security
An overly detailed and meticulously maintained RTM might give project stakeholders
a false sense of security about the project’s health and progress. This perception can
overshadow the need for proactive problem-solving and adaptability.
10. Difficulty in Measuring Impact
Quantifying the direct impact of an RTM on a project’s success can be challenging.
While it’s intended to improve traceability and accountability, demonstrating its
tangible benefits regarding return on investment (ROI) or project outcomes is not
straightforward.
Use Case Diagrams
Use case diagrams provide a visual
representation of how users interact
with the system. They identify the
actors, which represent users or
external systems, and the use cases,
which describe the actions that actors
can perform.
Characteristics:
Use Case Diagrams are a wid view of a system, but not a
deep one.
They do not model non-functional capabilities such as
business rules, constraints, quality of service
specifications, or similar capability needs.
Use Case Diagrams do not show sequence, order, or flow.
Use Case Diagrams do not model data in any way.
Use Case Diagrams do not include any Exception
behavior.
They just specify the needed functionality at a very high
level.

1 Actors 2 Use Cases 3 Relationships

Actors represent entities that Use cases describe the actions Relationships define how actors
interact with the system, such that actors can perform within and use cases are connected,
as users, external systems, or the system. indicating how they interact.
Advantages of Use Case
Diagrams

1. Use case help to capture the functional requirements of a system.

2. Use cases are traceable.
3. Use cases can serve as the basis for the estimating, scheduling, and
validating effort.
4. Use case can evolve at each iteration from a method of capturing
requirements, to development guidelines to programmers, to a test case and
finally into user documentation.
5. Use case alternative paths capture additional behavior that can improve
system robustness.
6. Use cases have proved to be easily understandable by business users, and
so have proven an excellent bridge between software developers and end
users.
Disadvantages of Use Case
Diagrams

1. Use cases were not created to capture non-functional requirements (e.g

performance, platform, scalability, reliability of a system).

2. The non-sequential nature of a use case diagram is often difficult for some

audiences to understand.

3. Learning how to write use cases takes time.

4. Use case specifications are not an appropriate tool for describing the user

interface of the application. Use cases should be left as UI independent as

possible.
 User Stories Diagrams
A visual exercise that helps product managers and
development teams define the work that will create the most
delightful user experience. It is used to improve your
understanding of your customers and to prioritize work.

Characteristics:
•Be complete enough to demonstrate user value.
•Be user-centric.
•Start with an epic.
•Be short, simple, and clear.
•Contain supporting files and documentation if necessary.
•Be comprehensive enough to demonstrate value, but simple enough to
develop in a single iteration.
•Be written based on the input of all stakeholders.
•Be flexible and negotiable without impacting other stories or features.
•Be easy to test.
•Include acceptance criteria (conditions of satisfaction) for testers.

User Story Elements

Story name User role Achievable Desired Acceptance
The story name Identify the role action Business Value Criteria
should be a very of the user for Identify the The acceptance
short title that whom the story business value This user story criteria helps
lets you and is written. the user hopes component tells you know when
others know to gain. you the value you have
what the story is the user hopes successfully
Advantages of User Stories
Diagrams

1. Focus on the user and make the team remain concentrated on providing

solutions to users’ problems;

2. Motivate and inspire the development team to be creative and critical when

creating solutions;

3. Help in time management when itemizing the development of conditions and

effectiveness;

4. Aid teamwork, as the team joins forces to find the best way to provide the

best service to the user and attain their dream;

5. Help prevent limitations that arise due to the definition of specification details

when they are defined too early on.

Disadvantages of User Stories
Diagrams

1. Lacks detailed documentation: The user story format may lead to ambiguity

and a lack of complete understanding of feature and requirement details.

2. Limited dependency visibility: Their focus on user needs can cause a lack

of dependency and interactions between user stories visibility. This can lead

to coordination issues.

3. Difficult to estimate effort: It lacks direct details estimating effort and

technical considerations, making it difficult to evaluate the time and resources

required
Activity Diagrams
Activity diagrams represent the workflow of a process or system. They show the activities
involved, the transitions between them, and the conditions that trigger these transitions.

1 2 3 4

Activities Transitions Conditions Swim Lanes

Rectangles represent Arrows show the flow Diamonds represent Swim lanes can be
individual activities of control between decision points where used to group
within the process. activities, indicating the flow of control activities based on
the order of can diverge based on different roles or
execution. certain conditions. departments.
Advantages of Activity
Diagrams

1. Illustrate the flow of activities so that it’s easy to understand the behavior and

structure of a system.

2. Allow stakeholders to visualize steps, decisions and interactions to root out

inefficiencies.

3. Provide a reference point for future developers or those involved in system

maintenance.
Disadvantages of Activity
Diagrams

1. They have the potential to become overly complex because their user-friendly

nature may lend itself to an all-inclusive description.

2. May not be used in lieu of a state diagram or sequence diagram because

"activity diagrams do not give detail about how objects behave or how objects

collaborate.
Sequence Diagrams Characteristics:
Sequence diagrams depict the interactions Sequence diagrams represent specific interactions, commonly known
between objects in a system over time. They as scenarios, among elements. A scenario is a specific interaction
show the order in which messages are among a set of elements, characterized by a specific set of messages
exchanged and the activation states of the arriving among the modeled elements in a specific order.
objects involved.
Lifelines

Vertical lines represent objects that participate in the interaction.

Messages

Arrows show the messages exchanged between objects, indicating the direction and type of communication.

Activations
Rectangles on the lifelines indicate the periods when an object is active and processing a message.
Advantages of Sequence
Diagrams

1. Clear visualization of interactions

One of the primary benefits of sequence diagrams is their ability to provide a clear
and concise visualization of the interactions between different objects over time.
2. Improved communication
Effective communication among team members is key to success in any
development project. Sequence diagrams are an excellent communication tool as
they visually represent the system’s behavior.
3. Enhanced documentation
Maintaining comprehensive and accurate documentation is essential for any
software project. Sequence diagrams play a critical role in documenting the
dynamic aspects of a system. They capture the flow of interactions in a manner
that text descriptions often cannot, providing a visual supplement to your
documentation.
4. Identifying design issues early
Sequence diagrams are invaluable for identifying potential design issues early in
the development process. By modeling the interactions between objects and
systems, you can spot inconsistencies, missing interactions, and potential
performance issues before they become problematic.
Advantages of Sequence
Diagrams

5. Facilitating test case generation

Another practical benefit of sequence diagrams is their utility in generating test
cases. Sequence diagrams provide a blueprint for creating test scenarios by
clearly outlining the expected sequence of interactions. This ensures that your
test cases are comprehensive and aligned with the designed interactions, leading
to more effective testing and higher-quality software.
6. Supporting agile development
They can be easily updated to reflect changes in requirements or design,
ensuring that your documentation and models stay current throughout the
development lifecycle. This adaptability makes sequence diagrams ideal for agile
teams striving for rapid and responsive development.
Disadvantages of Sequence
Diagrams

1. When the system has too many lifelines, sequence diagrams might get

complicated.

2. Incorrect results are generated if the message sequence's order is altered.

3. It may be a bit complicated to express each sequence using a distinct

message notation.

4. The kind of sequence in the graphic depends on the kind of message

Class Diagrams
Class diagrams model the structure of a system by representing the
classes, their attributes, and methods. They also define the relationships
between classes, such as inheritance, association, and aggregation.

Inheritance Represents a "is-a" relationship,

where one class inherits properties
and methods from another.

Association Shows a general relationship

between classes, indicating that
instances of one class can interact
with instances of another.

Aggregation Represents a "has-a" relationship,

where one class contains instances
of another class as part of its
composition.
Class Diagrams
Class diagrams model the structure of a system by representing the
classes, their attributes, and methods. They also define the
relationships between classes, such as inheritance, association, and
aggregation

Characteristics:
•Capture and define the structure of classes and other classifiers
•Define relationships between classes and classifiers
•Illustrate the structure of a model by using attributes, operations, and
signals
•Show the common classifier roles and responsibilities that define the
behavior of the system
•Show the implementation classes in a package
•Show the structure and behavior of one or more classes
•Show an inheritance hierarchy among classes and classifiers
•Show the workers and entities as business object models
Advantages of Class
Diagrams

1.They provide detailed insight into the structure of your systems. At the same

time they offer a quick overview of the synergy happening among the different

system elements as well as their properties and relationships.

2. A sense of orientation is given by the class diagrams. The structure of the

system is analyzed in detail by the class diagram, and also the synergy among

different elements is overviewed by them along with their properties.

Disadvantages of Class
Diagrams

1. The class diagrams might often take a longer time to manage, and maintain
which is sometimes annoying for a developer. It requires time for the
synchronization with the software code to set it up and maintain.
2. A lack of clarity in understanding the beneficiary of the diagram is also a
disadvantage. As software developers work with code, sometimes the class
diagrams are not that helped much.
3. An overcomplicated or overwhelming diagram doesn’t help software
developers in their work. There could be situations when the developers are
frustrated due to the structure of the class diagrams.
4. 4. Putting overemphasis on the design could cause a hindrance to the
developers and companies.
State Diagrams
State machine diagrams illustrate the possible states that an object can be in
and the transitions between these states. They define the events that trigger
state changes and the actions that are performed during each transition.

States Transitions
States represent the different Transitions represent the change
conditions that an object can be in. from one state to another,
triggered by events.

Events Actions
Events are external stimuli that Actions are the operations
can trigger state changes. performed during a transition,
such as sending a message or
updating data.
Advantages of State Diagrams

1. The lifecycle of an object, from initialization to release, can be modelled. This

increases the common understanding of the participants about the modelled

object.

2. The permitted states of an object and the events triggered by state transitions

can be described. This makes the behavior of the object visible and

comprehensible.

3. State diagrams can be used easily and in many situations, especially since

even inexperienced readers can easily understand them with a little practice.
Disadvantages of State
Diagrams

1. Complexity

One of the main limitations of state diagrams is that they can become quite

complex, particularly for large or complex systems.

2. Lack of Detail

Another limitation of state diagrams is that while they provide a visual

representation of a system’s behavior, they do not provide a detailed description

of how the system works. For that, additional documentation and analysis are

required.
Data Flow Diagrams
Data flow diagrams visualize the flow of data through a system. They identify data sources, data sinks, processes
that transform data, and data stores that hold data.

Data Sources Processes Data Stores Data Sinks

Represent entities that Represent activities or Represent places where Represent entities that
provide data to the transformations that are data is stored, such as receive data from the
system, such as users, performed on data within databases, files, or system, such as users,
external systems, or files. the system. repositories. external systems, or
reports.
Advantages of Data Flow
Diagram (DFD)

•It aids in describing the boundaries of the system.

•It is beneficial for communicating existing system knowledge to the users.

•A straightforward graphical technique which is easy to recognise.

•DFDs can provide a detailed representation of system components.

•It is used as the part of system documentation file.

•DFDs are easier to understand by technical and nontechnical audiences

•It supports the logic behind the data flow within the system
Disadvantages of Data Flow
Diagram (DFD)

•It make the programmers little confusing concerning the system.

•The biggest drawback of the DFD is that it simply takes a long time to create, so

long that the analyst may not receive support from management to complete it.

•Physical considerations are left out

Entity Relationship Diagrams
Entity relationship diagrams (ERDs) model the relationships between entities in a database. They show entities,
which represent objects or concepts, and their attributes, which represent properties of the entities.

Entities Relationships Attributes

Represent objects or concepts in Represent the connections Represent properties of entities,
the database, such as customers, between entities, indicating how such as customer name, product
products, or orders. they are related to each other. price, or order date.
Advantages of Entity Relationship
Diagram (ERD)

1. Simplicity and Clarity

They provide a clear and straightforward way to visualize data relationships. This
simplicity makes it easier for stakeholders, including non-technical team
members, to understand the structure of the database without needing in-depth
technical knowledge.
2. Effective Communication
ER Models serve as an excellent communication tool between database
designers, developers, and end-users. The visual nature of ER diagrams
facilitates better discussion and feedback, ensuring that all parties have a shared
understanding of the database structure.
3. Enhanced Documentation
An ER Model provides comprehensive documentation of the database structure.
This documentation is invaluable for future maintenance and updates, as it offers
a detailed map of how data is organized and interconnected.
4. Supports Database Design
ER Models are crucial during the database design phase. They help in organizing
data requirements systematically and identifying the relationships among different
data entities.
Advantages of Entity Relationship
Diagram (ERD)

5. Facilitates Data Integrity

By clearly defining relationships and constraints between data entities, ER
Models help maintain data integrity. For instance, primary and foreign keys can be
visually mapped, ensuring that referential integrity is upheld within the database.
6. Adaptability
ER Models are adaptable and can be easily modified to reflect changes in the
system’s requirements. This flexibility is essential in dynamic business
environments where data requirements may evolve over time. Being able to
update the ER Model to incorporate new data entities, relationships, or attributes
without disrupting the existing structure ensures that the database can grow and
adapt alongside the organization’s needs.
7. Promotes Efficient Querying
A well-structured ER Model can lead to efficient database querying. By
understanding the relationships and dependencies between entities, developers
can write optimized queries that enhance performance and speed up data
retrieval.
Disadvantages of Entity Relationship
Diagram (ERD)

1. Complexity in Large Systems

While ER Models are straightforward for smaller systems, they can become
exceedingly complex as the system grows. Large databases with numerous
entities and relationships can result in convoluted diagrams that are difficult to
read
2. Time Consuming Development
Creating an ER Model can be time-consuming, particularly for large and complex
databases. The process requires meticulous planning and detailed analysis to
ensure accuracy, which can delay the development timeline.
3. Limited Logical Design
ER Models primarily focus on the logical design of a database and do not directly
address physical database design. Additional steps are necessary to translate the
ER Model into a physical schema, which can introduce potential discrepancies if
not handled carefully.
Disadvantages of Entity Relationship
Diagram (ERD)

4. Hardness in Design
Once an ER Model is established, making significant changes can be
challenging. Any alteration in the database requirements might necessitate a
substantial redesign of the ER Model, which can be both time-consuming and
resource-intensive.
5. Potential for Oversimplification
In striving for simplicity, ER Models can sometimes oversimplify real-world
scenarios. Complex relationships and constraints might not be fully captured,
leading to a less accurate representation of the actual data requirements.
7. Scalability Issues
Scalability can be a concern with ER Models. As the amount of data and the
number of entities increase, maintaining and updating the ER Model can become
unwieldy, potentially hindering the database’s performance and manageability.
Requirements Modeling Elements
Below are the different strategies of requirements modeling:

Flow Oriented Modeling – The Class-based Modeling – Class-

data objects are transformed by the based modeling represents the
function as it is processed object. The system manipulates the
operations.
•Data Flow Model – It is a graphical
technique. It is used to represent •Classes – To figure out which
information flow. classes to take, underline each
•Control Flow Model – Large class noun or noun clause in the text and
applications require control flow enter it into the table.
modeling. •Attributes – Attributes are the data
•Control Specification – The state objects that define a class within
diagram in the control specification the context of the problem. For
is a sequential specification of the example, ’employee’ is a class
behavior. consisting of the name, Id,
•Process Specification – The department, designation, and
process specification is used to salary of the employee.
describe all flow model processes. •Operations – The operations
describe the actions of a thing.
Conclusion and Key Takeaways
Requirement modeling is an essential part of any software development project. It helps
ensure that the final product meets the needs of its users and aligns with business objectives.
By using a variety of modeling techniques, developers can create clear, comprehensive, and
maintainable requirements.
System Integration
& Architecture
COURSE DESCRIPTION
• The course discusses on how to design and build
systems and integrate them into an organization. It
covers to develop the skills to gather requirements,
then source, evaluate and integrate components into a
single system, and finally validate the system. It also
covers the fundamentals of project management and
the interplay between IT applications and organizational
processes.
LEARNING OBJECTIVES
• By the end of the course, students should be
able to:
• Analyze the appropriateness of a decision to in-
source or out-source IT services in a given situations.
• Create a testing environment and design a stress test
using appropriate tools and techniques that impact
system performance.
• Implement an enterprise integration middleware
platform.
COURSE REQUIREMENTS
• As part of this course, students will work on the
following:
• Assignment
• Quizzes
• Presentations
• Software Project
• Major Examinations
Learning Objectives
• The course focuses on how a proposed system will be
integrated with other existing or planned systems.
• It addresses the System Integration problem using
architectures as the basis and then addresses the
evaluation of the architectures in terms of the
capabilities they provide.
• To provide the students an understanding of the
technical and business process issues involved in
systems integration.
• Identify integration issues upfront in the process
of System Integration and should be able to
identify the best practices that ensure successful
System Integration.
System
• An array of components designed to accomplish
a particular objective according to plan. Many
sub-systems many be designed which later on
are combined together to form a system which is
intended to achieve a specific objective which
may be set by the Project manager.
Systems thinking
• Is a way of understanding an entity in terms of its
purpose, as three steps. The three major steps followed
in systems thinking
• 1. Identify a containing whole (system), of which the
thing to be explained is a part.
• 2. Explain the behavior or properties of the containing
whole.
• 3. Explain the behavior or properties of the thing to be
explained in terms of its role(s)or function(s) within its
containing whole
System Integration
• Is the combination of inter-related elements to
achieve a common objective (s).
• System integration is defined in engineering
as the process of bringing together the
component sub-systems into one system
System Architecture
• The architecture of a system defines its high-level
structure, exposing its gross organization as a collection
of interacting components.
• Elements needed to model a software architecture
include:
Components, Connectors, Systems, Properties
and Styles.
What is a project?
• From the key terms described above, a system
developer and architects cannot do anything without
first establishing various projects.
• These projects may be new or existing. So it is needs to
first understand what a project is, factors that influence
the project, who the owners are and many more.
• A project is a temporary endeavor undertaken to
accomplish a unique product or service
Where do Information Systems Projects
Originate (Sources of Projects)?
• New or changed IS development projects come from problems,
opportunities, and directives and are always subject to one or
more constraints.
• Problems – may either be current, suspected, or anticipated.
Problems are undesirable situations that prevent the business
from fully achieving its purpose, goals, and objectives (users
discovering real problems with existing IS).
• An Opportunity – is a chance to improve the business even
in the absence of specific problems. This means that the
business is hoping to create a system that will help it with
increasing its revenue, profit, or services, or decreasing its
costs.
• A Directive – is a new requirement that is
imposed by management, government, or some
external influence i.e. are mandates that come
from either an internal or external source of the
business.
What Helps Projects Succeed?
• According to the Standish Group’s report “CHAOS 2001: A Recipe for
Success,” the following items help IT projects succeed, in order of
importance:
• Executive support
• User involvement
• Experienced project manager
• Clear business objectives
• Minimized scope
• Standard software infrastructure
• Firm basic requirements
• Formal methodology
• Reliable estimates
Basic Organizational Structures
• Organizational structure depends on the company
and/or the project.
• The structure helps define the roles and responsibilities
of the members of the department, work group, or
organization.
• It is generally a system of tasks and reporting policies in
place to give members of the group a direction when
completing projects.
• A good organizational structure will allow people and
groups to work effectively together while developing
hard work ethics and attitudes.
Project Phases and the Project
Life Cycle
• A project life cycle is a collection of project phases.
• Project phases vary by project or industry, but some
general phases include concept, development,
implementation, support.
The Software Development Life
Cycle
• Planning. Defining the overall flow breaking down into
small, easy manageable parts is the start. All elements
are set in order to develop the project. An in-depth set
of functionalities is identified for each element. Suitable
technology is selected for the current product to be
implemented while planning phase.
• Analysis. It implicates identifying goals, demands
eliciting, transforming facts, diagnosing issues related
to the current project, recommending positive building.
While analysis it is created requirements in order the
scope of work to be defined.
• Design. Stakeholders review documented specification
for choosing a suitable approach. Applicable
requirements are used for the product’s architecture
design with limited functionality; also for identifying
approaches to be applied based on the design
document specification (DDS).
• Implementation stage is a start point of project
building. Code writing requires applying various
programming tools, languages to match the
documented specification. It helps in turning an idea
into a future solution.
• Testing and Integration. Bringing project’s separate
parts together into a test environment to be checked for
bugs, other fails for meeting standard criterion is
involved within mentioned stage.
• Maintenance. Systematically testing functionalities for
bugs that were not found or identified, for errors that
are not shown in the fail logs, those are vital
maintenance part that guarantees the project goes
within the planned requirements.
• Products also have life cycles.
• The Software Development Life Cycle (SDLC) is a framework
for describing the phases involved in developing and
maintaining information systems.
• Systems development projects can follow
• Predictive models: The scope of the project can be clearly
articulated and the schedule and cost can be predicted.
• Adaptive models: Projects are mission driven and
component based, using time-based cycles to meet target
dates.
Predictive Life Cycle Models
• The waterfall model has well-defined, linear stages of
systems development and support.
The waterfall model

Advantages Disadvantages A Good Fit

Tests are represented Errors should be fixed It fits not large projects
before every stage within the stage. with clear criteria.
finishing.

Every stage requires Testing comes quite late

elaborate documentation. in the building process.

Client’s feedback cannot

be included when
development is carried
out.
• The spiral model shows that software is developed using
an iterative or spiral approach rather than a linear
approach.
The spiral model

Advantages Disadvantages A Good Fit

Risk avoidance is reduced Expensive approach. It fits medium, large
based on high amount projects having chances
evaluation. of being implemented in
a meaningful way within
organisation based on
easy risk identification.
Possibility to add extra Project breakdown
features later. probability based on
defeat while analysing.
• The prototyping model is used for developing
prototypes to clarify user requirements.
The prototyping model

Advantages Disadvantages A Good Fit

Functionality conception Prototype creating is It fits large scale projects
based on prototyping based on the company's having exactly exhaustive
approach. expense. requirements that are
described after being
coded at first.
Investigating, analysis are Too much client’s
well-assessed. personal interest.
Adaptive Life Cycle Models
• Extreme Programming (XP): Developers program in
pairs and must write the tests for their own code. XP
teams include developers, managers, and users.
Extreme Programming (XP)

Advantages Disadvantages A Good Fit

Focusing on the client’s Effectiveness depends on It fits all types of projects
interest. project staffing profile. where criteria change
rapidly.
Establishing the Excessive changes can be
schedules, tasks in order frequently adopted.
the software engineers
will be involved into the
process.

Grouping with other Unknown exact

development approaches. possibilities, future
outcomes.
• Scrum: Repetitions of iterative development are
referred to as sprints, which normally last thirty
days. Teams often meet every day for a short
meeting, called a scrum, to decide what to
accomplish that day. Works best for object-oriented
technology projects and requires strong leadership
to coordinate the work.
The srum model

Advantages Disadvantages A Good Fit

Teams take decisions. Reliance on costs, time It fits all projects with
estimating accuracy. different complexity.

Requirements are Highly experts are

considered insignificant required.
for creating a successful
product.

Daily meetings are helpful

for outcomes measuring.
Requirements
• A system cannot be analyzed, designed, implemented
and evaluated unless the problem is understood and
requirements elicited.
• Requirements are fundamental basis of all the system
development processes.
• System architects will always base of the requirements
elicited by the system analyst to design an architectural
view of the system.
What are requirements?
• Requirements are statements that identify the essential
needs of a system in order for it to have value and
utility.
Characteristics of Good Req’ts
• Describes What, Not How.
• Atomic. i.e., it should have a single purpose
• Unique.
• Documented and Accessible.
• Identifies Its Owner.
• Approved. After a requirement has been revised,
reviewed, and rewritten, it must be approved by its owner.
• Complete
• Quantitative and testable
Requirements Life Cycle