requirements analysis for a broader coverage of this topic see requirements engineering a systems engineering perspective on requirements analysis software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte in systems engineering and software engineering requirements analysis 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 requirements of the various stakeholders 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 overview conceptually requirements analysis includes three types of activities eliciting requirements eg the project charter or definition business process documentation and stakeholder interviews this is sometimes also called requirements gathering or requirements discovery 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 naturallanguage documents use cases user stories process specifications and a variety of models including data models requirements analysis can be a long and tiring process during which many delicate psychological skills are involved large systems may confront analysts with hundreds or thousands of system requirements requirements quality can be improved through these and other methods visualization using tools that promote better understanding of the desired endproduct such as visualization and simulation consistent use of templates producing a consistent set of models and templates to document the requirements documenting dependencies documenting dependencies and interrelationships among requirements as well as any assumptions and congregations requirements analysis topics this section does not cite any sources please help improve this section by adding citations to reliable sources unsourced material may be challenged and removed october 2009 learn how and when to remove this template message stakeholder identification see stakeholder analysis for a discussion of people or organizations legal entities such as companies standards bodies that have a valid interest in the system they may be affected by it either directly or indirectly 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 anyone who operates the system normal and maintenance operators anyone who benefits from the system functional political financial and social beneficiaries anyone involved in purchasing or procuring the system in a massmarket product organization product management marketing and sometimes sales act as surrogate consumers massmarket customers to guide development of the product organizations which regulate aspects of the system financial safety and other regulators people or organizations opposed to the system negative stakeholders see also misuse case organizations responsible for systems which interface with the system under design those organizations who integrate horizontally with the organization for whom the analyst is designing the system joint requirements development jrd sessions requirements often have crossfunctional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews these crossfunctional implications can be elicited by conducting jrd sessions in a controlled environment facilitated by a trained facilitator business analyst wherein stakeholders participate in discussions to elicit requirements analyze their details and uncover crossfunctional implications a dedicated scribe should be present to document the discussion freeing up the business analyst to lead the discussion in a direction that generates appropriate requirements which meet the session objective jrd sessions are analogous to joint application design sessions in the former the sessions elicit requirements that guide design whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements contractstyle 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 long an appropriate metaphor would be an extremely long shopping list such lists are very much out of favour in modern analysis as they have proved spectacularly unsuccessful at achieving their aims but they are still seen to this day strengths provides a checklist of requirements provide a contract between the project sponsors and developers for a large system can provide a high level description from which lowerlevel requirements can be derived weaknesses such lists can run to hundreds of pages they are not intended to serve as a readerfriendly description of the desired application such requirements lists abstract all the requirements and so there is little context the business analyst may include context for requirements in accompanying design documentation this abstraction is not intended to describe how the requirements fit or work together the list may not reflect relationships and dependencies between requirements while a list does make it easy to prioritize each individual item removing one item out of context can render an entire use case or business requirement useless the list doesnt supplant the need to review requirements carefully with stakeholders in order to gain a better shared understanding of the implications for the design of the desired system application simply creating a list does not guarantee its completeness the business analyst must make a good faith effort to discover and collect a substantially comprehensive list and rely on stakeholders to point out missing requirements these lists can create a false sense of mutual understanding between the stakeholders and developers business analysts are critical to the translation process it is almost impossible to uncover all the functional requirements before the process of development and testing begins if these lists are treated as an immutable contract then requirements that emerge in the development process may generate a controversial change request alternative to requirement lists as an alternative to requirement lists agile software development uses user stories to suggest requirements in everyday language measurable goals goal modeling best practices take the composed list of requirements merely as clues and repeatedly ask why until the actual business purposes are discovered stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far such goals change more slowly than the long list of specific but unmeasured requirements once a 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 software prototyping a prototype is a computer program that exhibits a part of the properties of another computer program allowing users to visualize an application that has not yet been constructed a popular form of prototype is a mockup which helps future users and other stakeholders to get an idea of what the system will look like prototypes make it easier to make design decisions because aspects of the application can be seen and shared before the application is built major improvements in communication between users and developers were often seen with the introduction of prototypes early views of applications led to fewer changes later and hence reduced overall costs considerably prototypes can be flat diagrams often referred to as wireframes or working applications using synthesized functionality wireframes are made in a variety of graphic design documents and often remove all color from the design ie 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 as to whether the prototype represents the final visual look and feel of the application use cases use case a use case is a structure for documenting the functional requirements for a system usually involving software whether that is new or being changed each use case provides a set of scenarios that convey how the system should interact with a human user or another system to achieve a specific business goal use cases typically avoid technical jargon preferring instead the language of the enduser or domain expert use cases are often coauthored by requirements engineers and stakeholders use cases are deceptively simple tools for describing the behavior of software or systems a use case contains a textual description of the ways in which users are intended to work with the software or system use cases should not describe internal workings of the system nor should they explain how that system will be implemented instead they show the steps needed to perform a task without sequential assumptions requirements specification this section needs expansion you can help by adding to it february 2018 types of requirements this section may require cleanup to meet wikipedias quality standards no cleanup reason has been specified please help improve this section if you can february 2011 learn how and when to remove this template message requirements are categorized in several ways the following are common categorizations of requirements that relate to technical management customer requirements statements of fact and assumptions that define the expectations of the system in terms of mission objectives environment constraints and measures of effectiveness and suitability moemos the customers are those that perform the eight primary functions of systems engineering with special emphasis on the operator as the key customer operational requirements will define the basic need and at a minimum answer the questions posed in the following listing operational distribution or deployment where will the system be used mission profile or scenario how will the system accomplish its mission objective performance and related parameters what are the critical system parameters to accomplish the mission utilization environments how are the various system components to be used effectiveness requirements how effective or efficient must the system be in performing its mission operational life cycle how long will the system be in use by the user environment what environments will the system be expected to operate in an effective manner architectural requirements architectural requirements explain what has to be done by identifying the necessary systems architecture of a system structural requirements structural requirements explain what has to be done by identifying the necessary structure of a system behavioral requirements behavioral requirements explain what has to be done by identifying the necessary behavior of a system functional requirements functional requirements explain what has to be done by identifying the necessary task action or activity that must be accomplished functional requirements analysis will be used as the toplevel functions for functional analysis nonfunctional requirements nonfunctional requirements are requirements that specify criteria that can be used to judge the operation of a system rather than specific behaviors performance requirements the extent to which a mission or function must be executed generally measured in terms of quantity quality coverage timeliness or readiness during requirements analysis performance how well does it have to be done requirements will be interactively developed across all identified functions based on system life cycle factors and characterized in terms of the degree of certainty in their estimate the degree of criticality to system success and their relationship to other requirements design requirements the build to code to and buy to requirements for products and how to execute requirements for processes expressed in technical data packages and technical manuals derived requirements requirements that are implied or transformed from higherlevel requirement for example a requirement for long range or high speed may result in a design requirement for low weight allocated requirements a requirement that is established by dividing or otherwise allocating a highlevel requirement into multiple lowerlevel requirements example a 100pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lowerlevel items wellknown requirements categorization models include furps and furps developed at hewlettpackard requirements analysis issues stakeholder issues steve mcconnell in his book rapid development details a number of ways users can inhibit requirements gathering users do not understand what they want or users dont 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 this may lead to the situation where user requirements keep changing even when system or product development has been started engineerdeveloper issues possible problems caused by engineers and developers during requirements analysis are a natural inclination towards writing code can lead to implementation beginning before the requirements analysis is complete potentially resulting in inelegant refactoring to meet actual requirements once they are known technical personnel and endusers may have different vocabularies consequently they may wrongly 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 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 are also intended as solutions to problems encountered with previous methods 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 business analysis business analysis body of knowledge babok business process reengineering creative brief data modeling design brief functional requirements information technology modeldriven engineering model transformation language nonfunctional requirements process architecture process modeling product fit analysis requirements elicitation requirements engineering specialist group requirements management requirements traceability search based software engineering software prototyping software requirements software requirements specification systems analysis system requirements system requirements specification key elements of an enterprise software budget bibliography brian berenbach daniel paulish juergen katzmeier arnold rudorfer 2009 software systems requirements engineering in practice new york mcgrawhill professional isbn0071605479 hay david c 2003 requirements analysis from business views to architecture 1st ed upper saddle river nj prentice hall isbn0130282286 laplante phil 2009 requirements engineering for software and systems 1st ed redmond wa crc press isbn1420064673 mcconnell steve 1996 rapid development taming wild software schedules 1st ed redmond wa microsoft press isbn1556159005 nuseibeh b easterbrook s 2000 requirements engineering a roadmap pdf icse00 proceedings of the conference on the future of software engineering pp3546 citeseerx10111313116 doi101145336512336523 isbn1581132530 andrew stellman jennifer greene 2005 applied software project management cambridge ma oreilly media isbn0596009488 karl wiegers joy beatty 2013 software requirements 3rd ed redmond wa microsoft press isbn9780735679665 wikimedia commons has media related to requirements analysis peerreviewed encyclopedia entry on requirements engineering and analysis defense acquisition university stakeholder requirements definition process milhdbk 520 systems requirements document guidance vtemajor fields of computer sciencenote this template roughly follows the 2012 acm computing classification systemhardware printed circuit board peripheral integrated circuit very large scale integration systems on chip socs energy consumption green computing electronic design automation hardware acceleration computer systemsorganization computer architecture embedded system realtime computing dependability networks network architecture network protocol network components network scheduler network performance evaluation network service software organization interpreter middleware virtual machine operating system software quality software notationsand tools programming paradigm programming language compiler domainspecific language modeling language software framework integrated development environment software configuration management software library software repository software development software development process requirements analysis software design software construction software deployment software maintenance programming team opensource model theory of computation model of computation formal language automata theory computational complexity theory logic semantics algorithms algorithm design analysis of algorithms algorithmic efficiency randomized algorithm computational geometry mathematicsof computing discrete mathematics probability statistics mathematical software information theory mathematical analysis numerical analysis informationsystems database management system information storage systems enterprise information system social information systems geographic information system decision support system process control system multimedia information system data mining digital library computing platform digital marketing world wide web information retrieval security cryptography formal methods security services intrusion detection system hardware security network security information security application security humancomputerinteraction interaction design social computing ubiquitous computing visualization accessibility concurrency concurrent computing parallel computing distributed computing multithreading multiprocessing artificialintelligence natural language processing knowledge representation and reasoning computer vision automated planning and scheduling search methodology control method philosophy of artificial intelligence distributed artificial intelligence machine learning supervised learning unsupervised learning reinforcement learning multitask learning crossvalidation graphics animation rendering image manipulation graphics processing unit mixed reality virtual reality image compression solid modeling appliedcomputing ecommerce enterprise software computational mathematics computational physics computational chemistry computational biology computational social science computational engineering computational healthcare digital art electronic publishing cyberwarfare electronic voting video games word processing operations research educational technology document management book category portal wikiproject commons vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons vtesystems engineeringsubfields aerospace engineering biological systems engineering configuration management earth systems engineering and management electrical engineering enterprise systems engineering performance engineering reliability engineering safety engineering processes requirements engineering functional specification system integration verification and validation design review concepts business process system system lifecycle vmodel systems development life cycle tools decisionmaking function modelling idef optimization quality function deployment system dynamics systems modeling language systems analysis systems modeling work breakdown structure people james s albus ruzena bajcsy benjamin s blanchard wernher von braun kathleen carley harold chestnut wolt fabrycky barbara grosz arthur david hall iii derek hitchins robert e machol radhika nagpal simon ramo joseph francis shea katia sycara manuela m veloso john n warfield related fields control engineering computer engineering industrial engineering operations research project management quality management risk management software engineering category 