|
In sytems and software engineering, requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users. Requirements analysis is critical to the success of a project.[1] Systems engineering techniques are used in complex projects: from spacecrafts to chip design, from robotics to creating large software products to building bridges, Systems engineering uses a host of tools that include modeling & simulation, requirements analysis, and scheduling to manage complexity Systems Engineering (SE) is an interdisciplinary approach and means...
Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. ...
Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term "requirements analysis" can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance).
Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
This does not cite any references or sources. ...
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships between them. ...
Computer programming (often shortened to programming or coding) is the process of writing, testing, and maintaining the source code of computer programs. ...
Software testing is the process used to measure the quality of developed computer software. ...
Software deployment is all of the activities that make a software system available for use. ...
Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. ...
The Cleanroom Software Engineering process is a software development process intended to produce software with a certifiable level of reliability. ...
Iterative and Incremental development is a software development process developed in response to the weaknesses of the more traditional waterfall model. ...
Rapid application development (RAD), is a software development process developed initially by James Martin in the 1980s. ...
The Rational Unified Process (RUP) is an iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is an extensive refinement of the (generic) Unified Process. ...
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. ...
The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. ...
Extreme Programming (or XP) is a software engineering methodology, the most prominent of several agile software development methodologies. ...
Software Configuration Management (SCM) is part of configuration management (CM). ...
Software Documentation or Source Code Documentation is written text that accompanies computer software. ...
Project Management is the discipline of organizing and managing resources (e. ...
User experience design is a subset of the field of experience design which pertains to the creation of the architecture and interaction models which impact a users perception of a device or system. ...
Main techniques
Conceptually, requirements analysis includes three types of activity: - Eliciting requirements: the task of communicating with customers and users to determine what their requirements are.
- Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
- Recording requirements: Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops - see below) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. In software engineering and systems engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. ...
A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. ...
interview An interview is a conversation between two or more people (The interviewer and the interviewee) where questions are asked by the interviewer to obtain information from the interviewee. ...
A focus group is a form of qualitative research in which a group of people are asked about their attitude towards a product, service, concept, advertisement, idea, or packaging. ...
It has been suggested that this article or section be merged with prototype. ...
In software engineering and systems engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. ...
Stakeholder interviews Stakeholder interviews are a common method used in requirement analysis. Some selection is usually necessary, cost being one factor in deciding whom to interview. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.
Joint Requirements Development Sessions (a.k.a., Requirement Workshops) Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a Business Analyst, wherein stakeholders participate in discussions to elicited requirements, analyze their details and uncover cross-functional implications. A dedicated scribe to document the discussion is often useful, freeing the Business Analyst to focus on the requirements definition process and guide the discussion. The term Business Analyst (BA) is used to describe a person who practices the discipline of business analysis. ...
The term Business Analyst (BA) is used to describe a person who practices the discipline of business analysis. ...
Contract-style requirement lists One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages.
Measurable goals Best practices take the composed list of requirements merely as clues and ask why, repeatedly, until the actual business purposes are discovered. Then stakeholders and developers can devise tests to measure what level of each goal has been achieved so far. These goals change more slowly than the long list of specific but unmeasured requirements. Once the small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.
Prototypes -
In the mid-1980s, prototyping became seen as the solution to the requirements analysis problem. Prototypes are mock ups of the screens of an application which allow users to visualize the application that isn't yet constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of the screens led to fewer changes later and hence reduced overall costs considerably. It has been suggested that this article or section be merged with prototype. ...
However, over the next decade, while proving a useful technique, it did not solve the requirements problem:
- Managers once they see the prototype have a hard time understanding that the finished design will not be produced for some time.
- Designers often feel compelled to use the patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
- Prototypes principally help with design decisions and user interface design. However, they can't tell you what the requirements were originally.
- Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
Prototypes can be flat diagrams (referred to as 'wireframes') or a working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the software design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application. This article does not cite any references or sources. ...
Use cases -
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by software developers and end users. In software engineering and systems engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. ...
Economics and commerce define an end-user as the person who uses a product. ...
A domain expert or subject matter expert (SME) is a person with special knowledge or skills in a particular area. ...
Use cases are deceptively simple tools for describing the behavior of the software. A use case contains a textual description of all of the ways which the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show the steps that the user follows to use the software to do his work. All of the ways that the users interact with the software can be described in this manner.
During the 1990s, use cases rapidly became the most common practice for capturing functional requirements. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems, because use cases are not object-oriented in nature. For the band, see 1990s (band). ...
Object-oriented programming (OOP) is a computer programming paradigm in which a software system is modeled as a set of objects that interact with each other. ...
Each use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective, a use case describes just one feature of the system. For most software projects, this means that perhaps tens or sometimes hundreds of use cases are needed to fully specify the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case. Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. ...
A use case defines the interactions between external actors and the system under consideration to accomplish a business goal. Actors are parties outside the system that interact with the system; an actor can be a class of users, a role users can play, or another system.
Use cases treat the system as a black box, and the interactions with the system, including system responses, are as perceived from outside the system. This is deliberate policy, because it simplifies the description of requirements and avoids the trap of making assumptions about how this functionality will be accomplished. Black box is technical jargon for a device or system or object when it is viewed primarily in terms of its input and output characteristics. ...
A use case should:
- describe a business task to serve a business goal
- be at an appropriate level of detail
- be short enough to implement by one software developer in a single release
Use cases can be very good for establishing functional requirements, but they are not suited to capturing Non-Functional Requirements. However Performance Engineering specifies that each critical use case should have an associated performance oriented non-functional requirement. Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing and other specific functionality that show how the use cases are to be satisfied. ...
In systems engineering and requirements engineering, non-functional requirements are requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. ...
Performance engineering is the set of roles, skills, activities, practices, tools, and deliverables applied at every phase of the Systems Development Lifecycle which ensures that a solution will be designed and implemented to meet the non-functional requirements defined for the solution. ...
Software requirements specification - Further information: Functional specification
A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints). It has been suggested that Program specification be merged into this article or section. ...
In systems engineering and requirements engineering, non-functional requirements are requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. ...
Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.
Stakeholder identification A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include: For the band, see 1990s (band). ...
- those organizations that integrate (or should integrate) horizontally with the organization the analyst is designing the system for
- any back office systems or organizations
- Senior management
Problems
Stakeholder issues Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering: - Users don't understand what they want or user doesn't have clear idea of their requirement
- Users won't 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 don't understand the development process.
This may lead to the situation where user requirements keep changing even when system or product development has been started.
Engineer/developer issues Possible problems caused by engineers and developers during requirements analysis are: - Technical personnel and end users may have different vocabularies. Consequently, they can believe they are in perfect agreement until the finished product is supplied.
- Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.
- Analysis may be often carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client's needs properly.
Attempted solutions One attempted solution to communications problems has been to employ specialists in business or system analysis.
Techniques introduced in the 1990s like Prototyping, Unified Modeling Language (UML), Use cases, and Agile software development were also intended as solutions to problems encountered with previous methods. For the band, see 1990s (band). ...
It has been suggested that this article or section be merged with prototype. ...
In the field of software engineering, the Unified Modeling Language (UML) is a standardized specification language for object modeling. ...
In software engineering and systems engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. ...
Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. ...
Also, a new class of application simulation or application definition tools have entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer:
- electronic whiteboards to sketch application flows and test alternatives
- ability to capture business logic and data needs
- ability to generate high fidelity prototypes that closely imitate the final application
- interactivity
- capability to add contextual requirements and other comments
- ability for remote and distributed users to run and interact with the simulation
See also Business Process Reengineering is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. ...
Search Based Software Engineering (SBSE) is an approach to apply metaheuristic search techniques like genetic algorithms, simulated annealing and tabu search to software engineering problems. ...
This article does not cite its references or sources. ...
Almost all computer software requires some features to be present on a computer system before it can be used with the computer. ...
There are very few or no other articles that link to this one. ...
It has been suggested that Business analyst be merged into this article or section. ...
Information and communication technology spending in 2005 Information technology (IT), as defined by the Information Technology Association of America (ITAA), is the study, design, development, implementation, support or management of computer-based information systems, particularly software applications and computer hardware. ...
In software engineering and systems engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. ...
Process architecture is the structural design of general process systems and applies to fields such as computers (software, hardware, networks, etc. ...
// Definition The term process model is used in different kinds of contexts; most prominently business process models. ...
In computer science, data modeling is the process of applying a data model theory to create a data model instance. ...
Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing and other specific functionality that show how the use cases are to be satisfied. ...
In systems engineering and requirements engineering, non-functional requirements are requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. ...
Model-driven engineering (MDE) is an emerging technique in software, system and data engineering, based on the systematic use of models. ...
// The notion of Model transformation is of central importance to Information Technology. ...
// MDRE for SP in general This article is about market driven requirements engineering for software products (MDRE for SP). ...
Notes - ^ (March 2005) "Chapter 2: Software Requirements", in Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis: Guide to the software engineering body of knowledge, 2004 Version, Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Retrieved on 2007-02-08. “It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.”
Year 2007 (MMVII) is now the current year, a common year starting on Monday of the Gregorian calendar and the AD/CE era. ...
is the 39th day of the year in the Gregorian calendar. ...
Sources
External links |
Feeds |
Contact