- What is requirement?
- What is requirement Engineering?
- What are the requirement engineering processes?
- What is requirement Management?
- Why Requirement Management is important?
- What are the key requirement management skills?
- What are the artifacts used to manage requirements?
- What is requirement Management plan?
- What is Requirement Implementation?
- What are requirement sources?
- What are the main types of Requirements?
- What are the different statuses of requirement?
- What are FURPS?
- What is System Function Requirements?
- What is non-technical requirement?
- What are functional Requirements?
- What are non functional Requirements?
- What is user interface requirement?
- What is emergent property requirement?
- What is navigation requirement?
- What is implementation requirement?
- What are stable and volatile requirements?
- What are the different types of volatile requirements?
- What is measuring requirement?
- What are upgradeability requirements?
- What is program requirement?
- What is performance requirement?
- What is physical requirement?
- What is quantifiable requirement?
- What is an iteration plan?
- What is software Requirement specification?
- What is requirement elicitation?
- What is prioritizing a requirement?
- What is requirement validation?
- What are the processes of requirement validation?
- What is review Requirement?
- What are the main documents in requirement specification?
- What is product and process requirement?
- What is Requirement analysis?
- What is different elicitation technique?
- What is Use Case?
- What is use case section?
- What is Use case view?
- What is use case diagram?
- What is use case model?
- What is stake holder?
- What is stake holder request?
- What is the role of a system analyst?
- What is specification?
- What is software specification review (SSR)?
- What are the common requirement problems?
- Name some tools used for Requirement Management?
- What are the release requirement activities?
- What are the main qualities of Requirement set?
- What is traceability?
- What are the purposes of traceability?
- What is a traceability item?
- What are pre requirement and post requirement traceability?
- What is supplementary specification?
- What is vision document?
- Describe the vision document outline?
- What are the activities involved in problem analysis?
- What is a system?
- What is gold Plating?
- What is Gap analysis?
- How can we manage the requirement changes?
- What is change request?
- What are the activities involved in change analysis?
- What is scope Management?
- What are design constraints?
- What is requirement attribute?
- What is requirement database and what are the advantages of that?
- Why use requirement management database?
- Why requirement changes?
- What is requirement tracing?
- What are review records?
- What is Verification method, verification document?
- Tool Related What is the use of a requirement management tool?
- What is the difference between document centric and database centric requirement management tool?
- What are requirement modeling tool?
- What are requirement traceability tools?
- What is requirement tag?
- What is requirement text?
- What is traceability matrix?
- What is traceability tree?
- What are the minimum features that a requirement management tool must hace?
- What is cross project traceability?
A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. In systems engineering, a requirement can be a description of what a system must do.In other words A statement identifying a capability, physical characteristic, or quality factor that bounds a product or process need for which a solution will be pursued.
Requirements Engineering is the process of establishing the services that the customer requires from the system and the constraints under which it is to be developed and operated
- Feasibility study
- Requirements elicitation and analysis
- Requirements specification
- Requirements validation
- Requirements management
A systematic approach to eliciting, organizing and documenting the software requirements of the system, and establishing and maintaining agreement between the customer and the project team on changes to those requirements. Effective requirements management includes maintaining a clear statement of the requirements, along with appropriate attributes and traceability to other requirements and other project artifacts.
Requirements analysis is a colossal initial step in software development. Managing changing requirements throughout the software development life cycle is the key to developing a successful solution, one that meets users' needs and is developed on time and within budget. A crucial aspect of effectively managing requirements is communicating requirements to all team members throughout the entire life cycle. In truth, requirements management benefits all project stakeholders, end users, project managers, developers, and testers by ensuring that they are continually kept apprised of requirement status and understand the impact of changing requirements specifically, to schedules, functionality, and costs.
- Analyze the Problem
- Understand Stakeholder Needs
- Define the System
- Manage the Scope of the System
- Refine the System Definition
- Manage Changing Requirements
- Supplementary specification
- Use case specification
- Stake holder request
Describes the requirements artifacts, requirement types, and their respective requirements attributes, specifying the information to be collected and control mechanisms to be used for measuring, reporting, and controlling changes to the product requirements
Requirements implementation is the actual work of transforming requirements into software architectural designs, detailed designs, code, and test cases.
The term goal refers to the overall, high-level objectives of the software. Goals provide the motivation for the software, but are often vaguely formulated.
Domain knowledge: The software engineer needs to acquire, or have available, knowledge about the application domain. This enables them to infer tacit knowledge that the stakeholders do not articulate, assess the trade-offs that will be necessary between conflicting requirements, and, sometimes, to act as a "user" champion.
The operational environment: Requirements will be derived from the environment in which the software will be executed. These may be, for example, timing constraints in real-time software or interoperability constraints in an office environment. These must be actively sought out, because they can greatly affect software feasibility and cost, and restrict design choices.
The organizational environment: Software is often required to support a business process, the selection of which may be conditioned by the structure, culture, and internal politics of the organization. The software engineer needs to be sensitive to these, since, in general, new software should not force unplanned change on the business process.
- Functional Requirement
- Non Functional requirement
- User Requirement
- System Requirement
- TBD (to be defined)- this indicates that the value of the requirement has not been defined
- TBR (to be reviewed)- this indicates that a preliminary value is available but needs further review.
- Defined - This indicates that a final value for the requirement has been obtained through analysis and trades.
- Approved- The requirement has been reviewed and approved by the appropriate authorities.
- Verified- The requirement has been verified in accordance with the verification plan.
- Deleted - The requirement is no longer applicable to the program.
Functionality -It includes feature sets ,capabilities, security
Usability -It may include such subcategories as human factors (see Concepts: User-Centered Design), aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, training materials
Reliability - Reliability requirements to be considered are frequency and severity of failure, recoverability, predictability, accuracy, mean time between failures (MTBF)
Performance - A performance requirement imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for: speed, efficiency, availability, accuracy, throughput, response time, recovery time, resource usage
Supportability -Supportability requirements may include testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, localizability (internationalization)
These requirements specify a condition or capability that must be met or possessed by a system or its component(s). System functional requirements include functional and non-functional requirements. System functional requirements are developed to directly or indirectly satisfy user requirements.
Requirements like agreements, conditions, and/or contractual terms that affect and determine the management activities of a project
Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform.
It specifies actions that a system must be able to perform, without taking physical constraints into consideration. Functional requirements thus specify the input and output behavior of a systems
Non functional Requirements specify the qualities that the product must possess. These are things such as security, compatibility with existing systems, performance requirements, etc. In a product manufacturing example, non-functional requirements would be manufacturing requirements, or the conditions, processes, materials, and tools required to get the product from the design board to the shipping dock.
These are driven from Functional and Use Case Requirements, are traced from them both, depending on where they were derived from. They include items such as screen layout, tab flow, mouse and keyboard use, what controls to use for what functions (e.g. radio button, pull down list), and other "ease of use" issues.
Some requirements represent emergent properties of software—that is, requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate. Emergent properties are crucially dependent on the system architecture.
These are driven and traced from the Use Case, as the Use Case lists the flow of the system, and the Navigation Requirements depict how that flow will take place. They are usually presented in a storyboard format, and should show the screen flow of each use case, and every alternate flow. Additionally, they should state what happens to the data or transaction for each step. They include the various ways to get to all screens, and an application screen map should be one of the artifacts derived in this category of requirements.
An implementation requirement specifies the coding or construction of a system like standards, implementation languages, operation environment
Requirements changes occur while the requirements being elicited analyzed and validated and after the system has gone in to service
Stable requirements are concerned with the essence of a system and its application domain. They change more slowly than volatile requirements.
Volatile requirements are specific to the instantiation of the system in a particular environment and for a particular customer.
- Mutable requirements
- Emergent requirements
- Consequential requirements
- Compatibility requirements
As a practical matter, it is typically useful to have some concept of the "volume" of the requirements for a particular software product. This number is useful in evaluating the "size" of a change in requirements, in estimating the cost of a development or maintenance task, or simply for use as the denominator in other measurements. Functional Size Measurement (FSM) is a technique for evaluating the size of a body of functional requirements. What is requirement definition?
Upgradeability is our ability to cost-effectively deploy new versions of the product to customers with minimal downtime or disruption. A key feature supporting this goal is automatic download of patches and upgrade of the end-user's machine. Also, we shall use data file formats that include enough meta-data to allow us to reliably transform existing customer data during an upgrade.
These are not requirements imposed on the system or product to be delivered, but on the process to be followed by the contractor. Program requirements should be necessary, concise, attainable, complete, consistent and unambiguous. Program requirements are managed in the same manner as product requirements. Program requirements include: compliance with federal, state or local laws including environmental laws; administrative requirements such as security; customer/contractor relationship requirements such as directives to use government facilities for specific types of work such as test; and specific work directives (such as those included in Statements of Work and Contract Data Requirements Lists). Program requirements may also be imposed on a program by corporate policy or practice.
These are quantitative requirements of system performance, and are verifiable Individually. A performance requirement is a user-oriented quality requirement that specifies a required amount of performance
A physical requirement specifies a physical characteristic like materials, shape, size, weight a system must possess
The requirements have been grouped into "non-quantifiable requirements" and "quantifiable requirements." Quantifiable requirements are those whose presence or absence can be quantified in a binary manner. Non-quantifiable requirements are requirements that are not quantifiable.
A time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration
An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. The SRS document itself states in precise and explicit language those functions and capabilities a software system (i.e., a software application, an eCommerce Web site, and soon) must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents ,such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. SRS contains functional and nonfunctional requirements only; it doesn't offer designs suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be.
Requirements elicitation is concerned with where software requirements come from and how the software engineer can collect them. It is the first stage in building an understanding of the problem the software is required to solve. It is fundamentally a human activity, and is where the stakeholders are identified and relationships established between the development team and the customer. It is variously termed "requirements capture," "requirements discovery," and "requirements acquisition.
Prioritization will take the form of assigning requirements to categories such as "Must Have," "Needed," and "Desirable." "Must Have" requirements are defined as requirements that if not met will result in delay of the project. "Needed" requirements are defined as those requirements that require a very strong reason for not being met. "Desirable" requirements are defined as those requirements that if they are not met are open to negotiation
The requirements documents may be subject to validation and verification procedures. The requirements may be validated to ensure that the software engineer has understood the requirements, and it is also important to verify that a requirements document conforms to company standards, and that it is understandable, consistent, and complete. The aim is to pick up any problems before resources are committed to addressing the requirements. Requirements validation is concerned with the process of examining the requirements document to ensure that it defines the right software.
Requirements Reviews: A group of reviewers is assigned a brief to look for errors, mistaken assumptions, lack of clarity, and deviation from standard practice. The composition of the group that conducts the review is important and it may help to provide guidance on what to look for in the form of checklists. Reviews may be constituted on completion of the system definition document, the system specification document, the software requirements specification document, the baseline specification for a new release, or at any other step in the process.
Prototyping: Prototyping is commonly a means for validating the software engineer's interpretation of the software requirements, as well as for eliciting new requirements. As with elicitation, there is a range of prototyping techniques and a number of points in the process where prototype validation may be appropriate. The advantage of prototypes is that they can make it easier to interpret the software engineer's assumptions and, where needed, give useful feedback on why they are wrong.
Model Validation: It is typically necessary to validate the quality of the models developed during analysis. For example, in object models, it is useful to perform a static analysis to verify that communication paths exist between objects which, in the stakeholders' domain, exchange data. If formal specification notations are used, it is possible to use formal reasoning to prove specification properties.
Acceptance Tests: An essential property of a software requirement is that it should be possible to validate that the finished product satisfies it. An important task is therefore planning how to verify each requirement. In most cases, designing acceptance tests does this. Identifying and designing acceptance tests may be difficult for non-functional requirements to be validated; they must first be analyzed to the point where they can be expressed quantitatively.
To formally verify that the results of Requirements conform to the customer's view of the system.
The System Definition Document: This document records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers. The document lists the system requirements along with background information about the overall objectives for the system, its target environment and a statement of the constraints, assumptions, and non-functional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios and the principal domain entities, as well as data, information, and workflows.
System Requirements Specification: A System Requirements Specification is a document where the requirements of a system that is planned to be developed are listed. The document begins with an introductory description of the desired system. Except as noted below, the system is described in present tense, third person, active voice. The purpose of using present tense is to render this document historically relevant throughout the lifetime of the system. That is, the requirements specification is a permanent part of the system documentation, before the system is implemented, during implementation, and afterward
Software Requirements Specification: Software requirements specification establishes the basis for agreement between customers and contractors or suppliers on what the software product is to do, as well as what it is not expected to do. Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules. Software requirements specification provides an informed basis for transferring a software product to new users or new machines. Software requirements are often written in natural language, but, in software requirements specification, this may be supplemented by formal or semi-formal descriptions. Selection of appropriate notations permits particular requirements and aspects of the software architecture to be described more precisely and concisely than natural language. The general rule is that notations should be used which allow the requirements to be described as precisely as possible.
Product parameters are requirements on software to be developed. A process parameter is essentially a constraint on the development of the software. These are sometimes known as process requirements. Process requirements may also be imposed directly by the development organization, their customer, or a third party such as a safety regulator.
It is the process of understanding the problem and the requirements for a workable solution. Once the requirements have been gathered they become the basis for "Requirements Analysis". Analysis categorizes requirements and organizes them into related subsets, explores each requirement in relationship to others, examines requirement for consistency, omissions and ambiguity, and prioritizes requirements based on the needs of the customer
Scenarios: A valuable means for providing context to the elicitation of user requirements. They allow the software engineer to provide a framework for questions about user tasks by permitting "what if"and "how is this done" questions to be asked. The most common type of scenario is the use case.
Prototypes: A valuable tool for clarifying unclear requirements. They can act in a similar way to scenarios by providing users with a context within which they can better understand what information they need to provide. There is a wide range of prototyping techniques, from paper mock-ups of screen designs to beta-test versions of software products, and a strong overlap of their use for requirements elicitation and the use of prototypes for requirements validation
Facilitated meetings: The purpose of these is to try to achieve a summative effect whereby a group of people can bring more insight into their software requirements than by working individually. They can brainstorm and refine ideas which may be difficult to bring to the surface using interviews. Another advantage is that conflicting requirements surface early on in a way that lets the stakeholders recognize where there is conflict. When it works well, this technique may result in a richer and more consistent set of requirements than might otherwise be achievable.
Observation: The importance of software context within the organizational environment has led to the adaptation of observational techniques for requirements elicitation. These techniques are relatively expensive, but they are instructive because they illustrate that many user tasks and business processes are too subtle and complex for their actors to describe easily.
It is the description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains all flows of events related to producing the "observable result of value", including alternate and exception flows. More formally, a use case defines a set of use-case instances or scenarios. The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system
A use-case section is any section of a use case, including preconditions, post conditions, sub flows, steps, and text. Use-case sections can be used as traceability items.
An architectural view that describes how critical use cases are performed in the system, focusing mostly on architecturally significant components (objects, tasks, nodes). In the RUP, it is a view of the use-case model.
A diagram that shows the relationships among actors and use cases within a system.
An individual who is materially affected by the outcome of the system or the project(s) producing the system.
This artifact contains any type of requests a stakeholder (customer, end user, marketing person, and so on) might have on the system to be developed. It may also contain references to any type of external sources to which the system must comply.
The System Analyst role leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system; for example, identifying what actors exist and what use cases they will require when interacting with the system.
A declarative description of what something is or does. A document that fully describes a physical element or its interfaces in terms of requirements (functional, performance, constraints and physical characteristics) and the qualification conditions and procedures for each requirement.
In the waterfall life cycle, the major review held when the software requirements specification is complete.
- Poor Requirements Quality
- Over Emphasis on Simplistic Use Case Modeling
- Inappropriate Constraints
- Requirements Not Traced
- Missing Requirements
- Inadequate Verification of Requirements Quality
- Inadequate Requirements Validation
- Inadequate Requirements Management
- Inadequate Requirements Process
- Gatherspace (Gatherspace)
- RequisitePro (Rational)
- Doors (Telelogic)
- Prosareq (Insoft)
- Allocate baselined requirements to the release,
- Analysis of release requirements,
- Decomposition/development of release requirements (if necessary),
- Produce SRS for the release,
- Perform the SRR, and
- Release Change Control.
- Correct -It is a true statement of something the system must do.
- Complete -Describes all significant requirements of concern to the user
- Consistent -Does not conflict with other requirements
- Unambiguous -Is subject to one and only one interpretation
- Verifiable -Can be tested cost effectively.
- Ranked for importance and stability--Can be sorted based on customer importance and stability of the requirement itself.
- Modifiable -Changes do not affect the structure and style of the set.
- Traceable -The origin of each requirement can be found.
- Understandable -Comprehended by users and developers.
The ability to trace a project element to other related project elements, especially those related to requirements. Project elements involved in traceability are called traceability items
- Understand the source of requirements
- Manage the scope of the project
- Manage changes to requirements
- Assess the project impact of a change in a requirement
- Assess the impact of a failure of a test on requirements (i.e. if test fails the requirement may not be satisfied)
- Verify that all requirements of the system are fulfilled by the implementation.
- Verify that the application does only what it was intended to do.
Any project element which needs to be explicitly traced from another project element in order to keep track of the dependencies between them.
Pre-requirements traceability (pre-RT) refers to the ability to describe and follow those aspects of a requirement's life prior to its inclusion in the RS in both a forwards and backwards direction (i.e., requirements production and refinement).
Backward-from traceability Links requirements to their sources in other documents or people
Forward-to traceability Links other documents (which may have preceded the requirements document) to relevant requirements.
Post-requirements traceability (post-RT) refers to the ability to describe and follow those aspects of a requirement's life that result from its inclusion in the RS in both a forwards and backwards direction (i.e., requirements deployment and use).
Backward-to traceability Links design and implementation components backs to requirements Forward-from traceability Links requirements to the design and implementation components
The Supplementary Specification artifact capture system requirements that are not readily captured in behavioral requirements artifacts such as use-case specifications. ie the documents that cannot specify in the use case. Eg Performance requirement
- Communicates information between management, marketing, and the project team.
- Provides initial customer feedback.
- Fosters general understanding of the product.
- Establishes scope and priority of high-level stakeholder requests and features.
- A system-level document that describes the "what" and "why" of the product.
- Stakeholder and User Descriptions
- Product Overview
- Product Features
- Quality Ranges
- Precedence and Priority
- Other Product Requirements
- Documentation Requirements
- Feature Attributes
- Identify stakeholders.
- Understand the root causes.
- Gain agreement on the problem definition.
- Identify constraints on the system or project.
- Identify and validate the solution against the root causes.
- Define the solution system boundary
- Establish common vocabulary
A collection of connected units that are organized to accomplish a specific purpose. A system can be described by one or more models, possibly from different viewpoints.
Gold Plating is adding more requirements to the system than specified in the requirements.
It is an analysis of the gap between requirements that are met and not met; a deficiency assessment.
Managing requirement changes is an activity to identify, analyze, track, and report proposed changes and finally approve those changes to the product specification. As project evolves, requirements may change or expand to accommodate modifications in project scope or design. When there is a request to add a new feature to the product or to enhance an existing specification due to a defect or failure, a change request is created to modify the existing requirement specification. Those changes to the requirements can impact the project overall cost, resources allocated, and schedule planned for the delivery
The main processes of the change management are given.
Some requirements problem is identified. This could come from an analysis of the requirements, new customer needs, or operational problems with the system.
The requirements are analyzed using problem information and requirements changes are proposed. The proposed changes are analyzed .This checks how many requirements (and, if necessary, system components) are affected by the change and roughly how much it would cost, in both time and money, to make the change.
The change is implemented A set of amendments to the requirements document or a new document version is produced. This should, of course, be validated using whatever
Proposed changes are usually recorded on a change request form which is then passed to all of the people involved in the analysis of the change. Change request forms may include fields to document the change analysis data field responsibility field status field comments field
A general term for any request from a stakeholderto change an artifactor process. Documents in the Change Request are information on the origin and impact of the current problem, the proposed solution, and its cost. A type of stakeholderrequestthat specifies a new featureor functionality of the system
- The change request is checked for validity. Customers can misunderstand requirements and suggest unnecessary changes.
- The requirements which are directly affected by the change are discovered.
- Traceability information is used to find dependent requirements affected by the change.
- The actual changes which must be made to the requirements are proposed.
- The costs of making the changes are estimated.
- Negotiations with customers are held to check if the costs of the proposed changes are acceptable.
The process of protesting and determining the set of requirements that can be implemented in a particular release cycle, based on the resources and the time available. This process continues through out the life cycle of the project as the changes occurred
A requirement that includes information about the system design or architecture is a design constraint.
- An algorithm that is required to be used.
- A database system that is required to be used.
- A language that must be used in the implementation
Information associated with a particular requirement providing a link between the requirement and other project elements-for example, priorities, schedules, status, design elements, resources, costs, hazards.
Each requirement is represented as one or more Data base entities. Database query language is used to access requirements
The advantages of requirement data base are given.
- Good query and navigation facilities
- Support for change and version management
The statement of requirements - If there is a need to store more than just simple text, a database with multimedia capabilities may have to be used.
The number of requirements - Larger systems usually need a database which is designed to manage a very large volume of data running on a specialized database server.
Teamwork, team distribution and computer support - If the requirements are developed by a distributed team of people, perhaps from different organizations, you need a database which provides for remote, multisite access.
- Our understanding of the problem improved.
- The problem being solved changed.
- We failed to ask the right people the right questions at the right time.
- We failed to create or follow a process to help manage change.
- The users changed their minds or their perceptions.
- The external environment changed.
The linking of a requirement to other requirements and to other artifacts and their associated project elements.
The record created to capture the results of a review activity in which one or more project artifacts are reviewed.
Verification method - This attribute describes and tracks the selected verification method for the requirement. The alternatives are: inspection, analysis, demonstration and test.
Verification documents - This attribute provides a link to the number, title and paragraph number of the verification Plan and Procedure (such as a test plan) used to verify the requirement.
What is the use of a requirement management tool?
A database system for storing requirements.
Document analysis and generation facilities to help construct a requirements database and to help create requirements documents.
Change management facilities which help ensure that changes are properly assessed and costed.
Traceability facilities which help requirements engineers find dependencies between system requirements.
Manage versions and changes. Your project should define a requirements baseline, a specific collection of requirements that a particular release will contain. A history of the changes made to every requirement will explain previous decisions and let you revert to a previous version of a requirement if necessary.
Link requirements to other system elements. Tracing individual requirements to other system components helps ensure that your team doesn't inadvertently overlook any requirements during implementation. You can define links between different kinds of requirements and between requirements in different subsystems. When analyzing the impact of a change proposed in a specific requirement, the traceability links reveal the other system elements that the change might affect
Track Status. Tracking the status of each requirement during development supports overall project status tracking
View requirement subsets. You can sort, filter, or query the database to view subsets of the requirements that have specific attribute values.
Control access. You can set access permissions for users. Web access lets you share requirements information with all team members, even if they are geographically separated.
Communicate with stakeholders. Most requirements management tools let team members discuss requirements issues over email. Email can notify the affected people when a new discussion entry is made or a requirement is changed.
With a database-centric tool, requirements are primarily listed in a requirements database. The documents listing the requirements are secondary to the documents, which are generated from the database. A database-centric tool requires you to modify requirements by using the tool itself. Most database-centric tools use the requirement documents only to initially populate the requirements database or to output reports.
With a document-centric tool, requirements are primarily listed in a requirements document. A database exists only to "pull" requirements from the documents and to provide a dynamic, transitory repository when generating views and reports. Because requirements are located primarily within the document, anyone can update the requirements or create new ones. With a document-centric solution, information that helps explain or support the requirements, like attributes, images and graphs, can be included as part of the requirements document. A document-centric approach lets you work with the requirements independent of the requirements management tool.
Requirements modeling tools : These tools are used for eliciting, analyzing, specifying, and validating software requirements
Requirement traceability tools : These tools are becoming increasingly important as the complexity of software grows. Since they are also relevant in other life cycle processes, they are presented separately from the requirements modeling tools.
The requirement tag is the requirement's unique identifier. It consists of a prefix, which indicates the requirement type, and a number, which is generated by RequisitePro and which is unique within the requirement type.
Requirement text is the full textual content of a requirement. In the example above, the requirement text is the double-underlined sentence
Traceability Matrix illustrates the relationships between requirements of the same or different types. You use this matrix to create, modify, and delete traceability relationships and to view traceability relationships with a suspect state. You can also use the Traceability Matrix to filter and sort the row requirements and column requirements separately.
It displays all internal and external requirements traced to or from a requirement (depending on the direction of the tree). The Traceability Tree displays only the first level of traceability among requirements that reside in different projects (cross-project traceability). For example, if a requirement in your project is traced to a requirement in another project (external requirement), the external requirement is displayed in the Traceability Tree, but other requirements that the external requirement is traced to are not displayed in the tree.
- Utilize a database,
- Provide a numbering capability,
- Provide a distinct naming capability,
- Provide for both natural and formal language representations,
- Provide for multiple views of requirements (i.e., multiple diagramming capabilities),
- Provide a prioritization scheme,
- Provide traceability matrices,
- Provide for the recording of rationale and other notes about the requirements, and Provide traceability of changes.
RequisitePro's cross-project traceability feature helps you establish traceability between requirements that reside in different projects. It is helpful in storing requirements common to multiple projects.References
1. Rational Unified Process
2. Guide to the Software Engineering Body of Knowledge
3. Rational RequisitePro