requirements ieee standard glossary n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Requirements IEEE Standard Glossary PowerPoint Presentation
Download Presentation
Requirements IEEE Standard Glossary

Loading in 2 Seconds...

play fullscreen
1 / 45

Requirements IEEE Standard Glossary - PowerPoint PPT Presentation


  • 170 Views
  • Uploaded on

Requirements IEEE Standard Glossary. A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Requirements IEEE Standard Glossary


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
requirements ieee standard glossary
Requirements IEEE Standard Glossary
  • A condition or capability needed by a user to solve a problem or achieve an objective.
  • A condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

Computer Engineering 203 R Smith

Requirements Management 6/2009

quote from frederick brooks
Quote from Frederick Brooks
  • The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

Computer Engineering 203 R Smith

Requirements Management 6/2009

why are requirements critical
Why are Requirements Critical?
  • In over 8,000 projects conducted by 350 companies, only 16 percent of projects were considered successful, on time and within budget.
  • Studies continue to show that errors in requirements are the most significant factor in project failure.
  • Errors in requirements have the greatest impact on project resources, time, personnel, etc.
    • Costs to correct problems increase over time

Computer Engineering 203 R Smith

Requirements Management 6/2009

scope and requirements
Scope and Requirements
  • The text uses the term “scope” to cover both the project vision and requirements.
  • Think about project vision, scope and requirements as layers of detail.
  • Project vision being the highest level and requirements being the most detailed.
  • Each layer addresses a different need.

Computer Engineering 203 R Smith

Requirements Management 6/2009

scope and requirements1
Scope and Requirements
  • While each layer provides greater detail each layer must fit within the higher layers.
  • The Project Vision provides a filter to measure all requirements.
  • For example all requirements must be traced back to the project scope and the scope must fit within the project vision.

Computer Engineering 203 R Smith

Requirements Management 6/2009

vision scope statement
Vision/Scope Statement
  • Provides the answers to basic questions
    • What need will the project satisfy?
    • Who is the project for?
    • What is not in the project?
  • The Vision statement provides a base to trace all requirements too.
  • The Vision statement help establish project buy-in.

Computer Engineering 203 R Smith

Requirements Management 6/2009

from vision to requirements
From Vision to Requirements
  • The Vision/Scope sets the framework, creating requirements adds detail.
  • All code that is written for a project should be in response to a requirement.
  • The Vision justifies all other work

Computer Engineering 203 R Smith

Requirements Management 6/2009

what makes good requirement
What Makes Good Requirement?
  • All stakeholders have the same vision of the requirement.
  • That it can be built and tested.
  • The end result of different developers each developing the same requirement will be essentially the same.

Computer Engineering 203 R Smith

Requirements Management 6/2009

unambiguous
Unambiguous
  • All readers of a requirement statement should arrive at a single consistent interpretation of it.
  • How to achieve unambiguous requirements:
    • Ensure the frame of reference is consistent
    • Use modeling, UML
    • Use prototypes

Computer Engineering 203 R Smith

Requirements Management 6/2009

necessary
Necessary
  • Each requirement should document something the customer needs.
    • The need can be traced back to the vision.
  • The Vision can be traced back to the customer.

Computer Engineering 203 R Smith

Requirements Management 6/2009

complete
Complete
  • Is each requirement fully described?
  • Does the developer have all the information needed to begin design?
  • Will the developer need to refer to the customer for missing details?

Computer Engineering 203 R Smith

Requirements Management 6/2009

realistic
Realistic
  • Is the requirement beyond the limitations of the systems environment?
  • Is the requirement beyond the scope of technology?

Computer Engineering 203 R Smith

Requirements Management 6/2009

verifiable
Verifiable
  • Can tests be written to verify that the requirement can be met?
    • Can you write a test that verifies that a user interface is:
      • “Good”
      • “Easy to use”
  • Can it be determined objectively if a requirement has been met?

Computer Engineering 203 R Smith

Requirements Management 6/2009

consistent
Consistent
  • Do requirements conflict with other requirements?
  • Being easy to “learn” and “feature rich” are often in conflict.
  • Developing something in a set time frame and having a limited budget are often in conflict.

Computer Engineering 203 R Smith

Requirements Management 6/2009

traceable
Traceable
  • Traceable goes in both directions
    • External to the customer
    • Internal to the code
  • Can you trace the requirement back to the customer?
  • Can elements, code, test cases and documentation be traced to a requirement?
  • If code does not implement a requirement then why is it being implemented?

Computer Engineering 203 R Smith

Requirements Management 6/2009

why are good requirements important
Why are Good Requirements Important?
  • Improved Efficiency
    • Reduces delays for clarification.
  • Less Rework
    • Getting it right the first time reduces waste.
  • Reduced Risk
  • Less Friction
    • Giving the customer what they want.

Computer Engineering 203 R Smith

Requirements Management 6/2009

scope and requirements2
Scope and Requirements
  • Does user involvement solve everything?
    • Is the user fully informed?
      • Do they have authority?
    • Is what is in and what is not included clearly described?
      • Assumptions are made too easily
    • Is a change control mechanism provided.
      • Ensure changes happen in planned manner
    • Communications
      • Everyone is informed when changes happen

Computer Engineering 203 R Smith

Requirements Management 6/2009

role of a requirements process
Role of a Requirements Process
  • Provides discipline to make requirements gathering predictable.
  • Communicates to those involved what is expected of them.
  • Establishes a baseline for future improvement to gathering requirements.

Computer Engineering 203 R Smith

Requirements Management 6/2009

why is a requirements process needed
Why is a requirements process needed?
  • Ensure quality in establishing the requirements.
  • Change will always be expensive.

Computer Engineering 203 R Smith

Requirements Management 6/2009

steps in the requirements process
Steps in the Requirements Process
  • Requirements Elicitation
    • How are we going to get the requirements?
    • From whom do we get requirements?
  • Requirements Analysis
    • What do the requirements actually mean?
  • Requirements Documentation
    • Making a record of the decisions made.
  • Requirement Verification
    • Getting agreement on the work to be done.

Computer Engineering 203 R Smith

Requirements Management 6/2009

common problems with requirements
Common Problems with Requirements
  • Requirements are not Consistent with the Vision.
  • Requirements are ambiguous and are based on assumptions, which allows multiple interpretations.
  • Requirements are based on the design and not the Vision.

Computer Engineering 203 R Smith

Requirements Management 6/2009

common problems with requirements1
Common Problems with Requirements
  • All sources of requirements are not identified.
  • All stakeholders are not informed of the requirements.

Computer Engineering 203 R Smith

Requirements Management 6/2009

relationship between planning and requirements
Relationship between Planning and Requirements
  • You need requirements to have a completed plan.
  • You need a plan too know if your requirements can be successfully implemented.

Computer Engineering 203 R Smith

Requirements Management 6/2009

where do requirements come from
Where do Requirements come from?
  • Customers
  • Industry standards
  • Business goals
  • Company priorities
  • Government standards

Computer Engineering 203 R Smith

Requirements Management 6/2009

types of requirements
Types of Requirements
  • Functional requirements
  • Nonfunctional and Pseudo requirements
  • Systems requirements
  • User requirements
  • Business requirements
  • Quality attributes

Computer Engineering 203 R Smith

Requirements Management 6/2009

functional requirements
Functional Requirements
  • Behavior of the system
  • Operations it should perform
  • Inputs it should accept
  • Output it should produce

Computer Engineering 203 R Smith

Requirements Management 6/2009

nonfunctional and pseudo requirements
Nonfunctional and Pseudo Requirements
  • Industry/Company standards
    • Windows Look and Feel
  • Government regulations
    • How records are kept
  • Market requirements
    • Internet/X.400

Computer Engineering 203 R Smith

Requirements Management 6/2009

best practices in requirements elicitation
Best Practices in Requirements Elicitation
  • Have a vision and scope statement
    • Agree on the project’s objective
  • Define the requirements procedure
  • Identify users/stakeholders
    • Where do we get requirements from
  • Involve the user
  • Analyze user workflow
    • Uncover what assumptions have been made.

Computer Engineering 203 R Smith

Requirements Management 6/2009

requirements analysis
Requirements Analysis
  • Draw a system context diagram
  • Create models and prototypes
  • Create a data dictionary
  • Analyze feasibility
  • Prioritize requirements
  • Risk Management

Computer Engineering 203 R Smith

Requirements Management 6/2009

create models and prototypes
Create Models and Prototypes
  • Use Cases
  • Data Flow Diagrams
  • Entity Relationship Diagrams
  • State Transition Diagrams

Computer Engineering 203 R Smith

Requirements Management 6/2009

create a data dictionary
Create a Data Dictionary
  • The Data Dictionary is the glue that holds requirements and models together.
  • Primitive data elements
  • Data structures or records
  • Iterations within data structures

Computer Engineering 203 R Smith

Requirements Management 6/2009

analyze feasibility
Analyze Feasibility
  • Determine the risks
    • Unfamiliar tools, technologies, methods, hardware, etc
  • How complex is it?
  • How rigid are the requirements?

Computer Engineering 203 R Smith

Requirements Management 6/2009

prioritize requirements
Prioritize Requirements
  • Look at the risks.
  • Look at the dependencies.
  • Look at the availability of resources.
  • Look at customer interest.
    • What will make the customer happy.
  • Look at visibility.
    • Can we show progress?

Computer Engineering 203 R Smith

Requirements Management 6/2009

risk management
Risk Management
  • How do risks impact the requirements?
  • What are priorities?
  • What requirements can be delayed to make time to allow for risks?

Computer Engineering 203 R Smith

Requirements Management 6/2009

traceability matrix
Traceability Matrix
  • Best practice would establish a traceability matrix for all requirements.
  • All code, tests and documentation must trace back to a requirement.
  • Requirements must have associated code, tests and documentation.
  • The matrix ties everything together.

Computer Engineering 203 R Smith

Requirements Management 6/2009

best practices in documenting requirements
Best Practices in Documenting Requirements
  • Requirements should be inspected
    • Unambiguous
    • Measurable
  • Use writing standards, common syntax when documenting requirements
  • Define all data
  • Use pictures and diagrams

Computer Engineering 203 R Smith

Requirements Management 6/2009

requirements verification
Requirements Verification
  • Inspect requirements documents
    • Look for common errors
  • Write test cases from requirements
  • Write user manual from requirements
  • Is sign-off enough?
    • If there is not informed buy-in then there is always room for disagreement.

Computer Engineering 203 R Smith

Requirements Management 6/2009

inspect requirements documents
Inspect Requirements Documents
  • Doing formal inspections of requirements eliminates requirements problems early in the development process
  • Builds a common understanding of the requirements

Computer Engineering 203 R Smith

Requirements Management 6/2009

is sign off enough
Is Sign-off Enough?
  • Is sign-off enough if you know the work is sub-par?
  • Avoided problems will come back to haunt you.
  • Was the sign-off done after careful review or was it done because it was expected in the schedule?

Computer Engineering 203 R Smith

Requirements Management 6/2009

requirements management
Requirements Management
  • From Requirements to Project Plans
  • Change Control
  • Version Control
  • Requirements Tracing
  • Requirements Status Tracking

Computer Engineering 203 R Smith

Requirements Management 6/2009

from requirements to project plans
From Requirements to Project Plans
  • Creating the roadmap
    • Priorities
    • Estimates
    • Risks
    • Dependencies

Computer Engineering 203 R Smith

Requirements Management 6/2009

change control
Change Control
  • Change Control Boards
  • Use of contingency in estimating the size of the work

Computer Engineering 203 R Smith

Requirements Management 6/2009

version control
Version Control
  • Tracking when requirements were added or dropped
  • Tracking who and why a change was requested
  • Tracking the impact of the change
  • Tracking who approved the change

Computer Engineering 203 R Smith

Requirements Management 6/2009

requirements tracing
Requirements Tracing
  • What is needed to justify the work involved in tracing requirements?
    • Customer satisfaction
    • Not doing more work then required
    • Ensuring that all parts of the project come together
      • Documentation
      • Support
      • Test

Computer Engineering 203 R Smith

Requirements Management 6/2009

requirements status tracking
Requirements Status Tracking
  • As part of normal schedule tracking, follow the progress of development.
  • Allow for partial releases of functionality within status tracking.

Computer Engineering 203 R Smith

Requirements Management 6/2009