Requirements Analysis and

Design
Requirement Analysis
• Serves as a foundation for test plans and project plan
• Serves as an agreement between developer and customer
• Process to make stated and unstated requirements clear
• Process to validate requirement for completeness, unambiguity and
feasibility.
Requirements Analysis and Design
• Business Requirements – They are high-level requirements that are
taken from the business case from the projects.
• Architectural & Design Requirements –It determines the overall
design required to implement the business requirement.
• System & Integration Requirements – It is detailed description of each
and every requirement. It can be in form of user stories which is really
describing everyday business language.
Object Oriented Analysis
• Object-oriented approaches help us decompose the system
functionality in such a way that humans can wrap their head around
the design of the system.
• On the other hand, the incorporation of objects as an evolving
process in which OO techniques are gradually integrated into
mainstream SDLC.
• In practice, many large software projects have an object-oriented
orientation to them.
• UML stands for the Unified Modeling Language, and it's a
diagramming language.
Object Oriented Analysis
• One of the concepts that makes object-oriented development so
attractive is the concept of inheritance. Inheritance allows reusing
parts of the system, so that we don't have to write the same code
twice
• In inheritance, we extract common attributes and methods of classes
into something called a superclass. A superclass allows us to
consolidate the properties, attributes, methods of objects where
appropriate.
• Subclasses then share the attributes and methods of the superclass,
but they add additional detail.
Object Oriented Analysis
• Look at employees and customers and one of the things we notice is
that without inheritance, they share a lot of common things. Without
inheritance, we would end up writing two different classes that had a
lot of duplicate functionality.
• With inheritance we pull the common attributes and methods into a
superclass. In this example, the superclass is person. We then create
two subclasses that hold just the information required for those specific
classes.
• So, for example, for employees, we might want to track the hire date
and the pay grade, for customers, we might want to track the date of
their last contract.
Use Case Diagram
Class Diagram
Sequence Diagram
• What's the sequence so to speak, of events in which the actor
interacts with the classes?
• A sequence diagram visually depicts the procedures or the steps in a
use case, at the system level that shows in effect what the software is
doing or the steps that the software needs to take to perform a
certain action or calculation.
• The sequence diagrams help developers better understand the
sequence of events. They can often be verified with the business
users to make sure that they are correct and complete before
proceeding to writing code.
Sequence Diagram
State Chart Diagram
• When we introduced classes and objects, we talked about the fact
that objects carry a particular state. That state could be things like the
example of a car, it starts out as being owned and then it might go
into for sale, and then offer pending and then sold.
• The basic elements of the state chart diagram are the initial state, the
final state, intermediate states, which are typically represented by
boxes, sometimes with rounded corners. And then the transitions,
represented with arrows.
Activity Diagram
Statechart Diagram
Verification vs Validation
• Validation: Are we building the right system?
• Verification: Are we building the system right?
• Validation is the process of checking whether the specification captures
the customer’s needs, while verification is the process of checking that
the software meets the specification.
• Validation includes activities such as requirements modelling,
prototyping and user evaluation.
• Verification includes all the activities associated with producing high
quality software: testing, inspection, design analysis, specification
analysis
Functional Decomposition

Traditional OOAD
Design Phase
• Determining the preferred system acquisition strategy. This is
essentially a make versus buy decision.
• All of these covered at a very high level because the business analyst
typically isn't doing these tasks but does need to participate in them
in an intelligent way.
• We don't develop most of these deliverables, but our job is to
continue to advocate for the user to make sure that the business
needs and requirements of the system are met.
Design Phase
• If we're going to do it in-house, then we effectively have only one
option, which is develop it in-house with our own developers.
• We can outsource it, in which case we might bring in a consulting firm
that specializes in business systems development. We can go with the
hosted provider. Sometimes called software as a service or an
application service provider, ASP, sometimes called renting, or we can
go with a hosted solution.
• Who in your organization has the decision rights for whether a project
is developed in-house or outsourced? This decision is typically made at
a very high level within the organization, usually with input from the
bottom-up.
Design Phase
• Outsource can have a variety of meanings: If we choose to go with
someone else, we can either outsource it to a consulting firm or we could
offshore that development.
• It's important though that we don't outsource what we don't understand.
Managing the outsourcing relationship is a full-time job and you still need
to track vendors to deliver a system that meets your requirements.
• Whether you offshore or not is largely a decision based on cost, as well as
other factors, such as protection of any intellectual property or private
data that you might be concerned about. The pros of developing our
system ourselves is that, it allows us to control the system look, as well as
the functionality.
Design Phase
• On the other hand, developing the software in-house is often the
costliest option in the long-run. This cost can be offset by some sort of
competitive advantage or pro-activity gain you can't get with
commercial software.
• If we outsource, on the other hand, it allows us generally to complete
this faster. Outsource companies generally can scale their resources to
meet timelines much easier. They also might have better expertise in
completing these types of projects.
Design Phase
• It's important in selecting the right vendor as well as compare
between values, priorities, and culture between your organization and
the outsource vendor.
• There might be a choice to go with an external provider, sometimes
called software as a service, or a hosted provider. This is software
that's generally hosted and managed by the provider and delivered on
a one to many, sometimes called a multi-tenant model.
• The revenue or expense pattern for this is often a subscription, be it
monthly or annual. The classic example of outsourcing to a SaaS
provider, is salesforce.com
Design Phase

• Traditional CRM software installed on-premise at the customer's site.

• With salesforce.com, you just sign up for a user account and pay a
monthly fee to get access to their software.
• Pros: An army of developers ensuring that the software is up-to-date
and constantly adding features. It allows you to react with agility.
• Cons: it's more of a commodity model, so there is less control over
the service quality.
• Limitations on competitive advantage.

Acknowledgement: Coursera Business Analysis