2. Why?
● To accurately estimate project costs, precise requirements are needed.
– Even small changes in requirements can sometimes cause a large impact to project
costs
– Changes in requirements are more expensive the later they occur in the project life
cycle
– Getting requirements right saves time, money and usually ensures a project’s success
3. Before you start
● Understand the difference between technical requirements and business requirements
● The customer must establish baseline technology platform demanded by the business
● Example 1 –
– Customer says, “We need to display some financial transaction data from SAP within the Marketing
Team site in SharePoint 2010.”
In this case, use of SAP and SharePoint become business requirements (not technical requirements)
Example 2 –
– Customer says, “We need to share some financial data with some users that are outside of the
finance department.”
In this case, the consultant can propose appropriate technologies (such as SAP and SharePoint) but
these become technical requirements, not business requirements.
4. It's difficult to build a solution if you don't know the requirements (in spite of the fact that many
teams still try to do it today!).
● The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.
● The goal of requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.
Requirements analysis in and , encompasses those tasks that go into determining the needs or
conditions to meet for a new or altered product or project, taking account of the possibly
conflicting of the various , analyzing, documenting, validating and managing software or system
requirements.
Requirements analysis is critical to the success or failure of a systems or software project. The
requirements should be documented, actionable, measurable, testable, traceable, related to
identified business needs or opportunities, and defined to a level of detail sufficient for system
design
Requirements- An Introduction
5. Conceptually, requirements analysis includes three types of activities:[]
business process documentation and stakeholder interviews. This is sometimes also called
requirements gathering.
Analyzing requirements: determining whether the stated requirements are clear, complete,
consistent and unambiguous, and resolving any apparent conflicts.
Recording requirements: Requirements may be documented in various forms, usually
including a summary list and may include natural-language documents or process
specifications.
Managing Requirements
7. Described as a set of inputs, the behavior, and outputs.
→ Design area scope: Description of which business requirements will be automated.
→ System Functionality: How the user will interact with the software. These are often
documented with Use Cases.
→ Data Definitions: What the business data will look like, allowable values, default values, field
lengths etc.
→ Quality Attributes: Descriptions that indicate how well the system performs a behaviour or
lets the user take some action.
→ User classes: Groups of people who will be using the new application software or process
(actors, external agents).
→ User Interfaces: Screen layouts, report layouts and procedural descriptions.
→ Performance Standards: Volume of transactions, number of users, speed of response, etc
→ Security Requirements: Levels of access required, password length and type, audits and/ or
logging required.
Examples :-
→ Search option given to user to search from various invoices
Functional Requirements
8. - which are not related to functional aspect of software.
- aspects that your system must fulfill, such as performance-related issues, reliability
issues, and availability issues
- A technical requirement that describes specifically how the business problem will be
solved, and reflects the view from the technical world. This includes….
→ Hardware Descriptions: Are there specific types or brands of hardware that must be
used?
→ Software Descriptions: What development tools will be used, and what programming
language? Database design and data conversion requirements.
→ Design Flows: Diagrams and descriptions that depict how programs and other system
components interface with each other
●
Examples :-
Security, Storage, Performance, Cost, Accessibility
Non-Functional Requirements(Technical Requirements)
9. The Importance of GOOD Requirements
We don’t just need requirements we need good requirements which are clear and specific.
Poor requirements can easily be interpreted in many different ways…
10. What is a GOOD Requirement?
Complete (express a whole idea or statement)
• Correct (technically and legally possible)
• Clear (unambiguous and not confusing)
• Verifiable (it can be determined that the system meets the requirement)
• Necessary (should support one of the project goals)
• Feasible (can be accomplished within cost and schedule)
• Prioritized (tracked according to business need levels)
• Consistent (not in conflict with other requirements)
• Traceable (uniquely identified and tracked)
• Modular (can be changed without excessive impact)
• Design-independent (do not pose specific solutions on design)
11. → Ask Questions- you job is to help the business solve a problem. It’s not always what the person says
that’s important, sometimes its how they say it that you need to pay attention to.
→ Listen- Listen to what the business is saying. If you are really listening, what they tell you will lead you
to what questions you need to ask.
→ Feedback- next, your job is to provide feedback of what you heard to ensure you understood
correctly what they were saying. Do this by repeating back to them what you heard them say using
paraphrasing or mirroring their words.
→ Agreement- ensure you have agreement from the business of what the requirement really is.
Top Tips for Getting Good Requirements
12. Requirement Engineering Process
It is a four step process, which includes –
● Feasibility Study
● Requirement Gathering
● Software Requirement Specification
● Software Requirement Validation
13. ● Feasibility study
analysts does a detailed study about whether the desired system and its functionality are
feasible to develop.
● Requirement Gathering
engineers communicate with the client and end-users to know their ideas on what the software
should provide and which features they want the software to include.
● Software Requirement Specification
document created by system analyst after the requirements are collected
● Software Requirement Validation
requirements mentioned in this document are validated
14. Requirement Gathering Techniques
● Communicating with client, end users, system users and others who have a stake in the software
system development.
● Interviews
● Surveys
● Questionnaires
● Task analysis-analyze the operation for which the new system is required
● Domain Analysis
● Brainstorming-informal debate is held among various stakeholders & Record it
15. Requirements Analysis issues
● Stakeholder issues
– Users do not understand what they want or users don't have a clear idea of their requirements
– Users will not commit to a set of written requirements
– Users insist on new requirements after the cost and schedule have been fixed
– Communication with users is slow
– Users often do not participate in reviews or are incapable of doing so
– Users are technically unsophisticated
– Users do not understand the development process
– Users do not know about present technology
● Engineer/developer issues
Not clear the Requirement and start developing
● Communication issue
Communication issue will cause the requirement analysis
