http://13.50.150.85/api.php?action=feedcontributions&feedformat=atom&user=JohDTU ProjectLab - User contributions [en-gb]2026-07-15T07:06:10ZUser contributionsMediaWiki 1.43.3http://13.50.150.85/index.php?title=Requirements_engineering&diff=6956Requirements engineering2014-12-01T22:40:19Z<p>Joh: /* Non-functional requirements */</p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements<ref name="snow">["http://www.informit.com/articles/article.aspx?p=1929849&seqNum=15"] ''Snow Card Template - InformIT'' </ref>]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes<ref name="QualityPic">["https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en"] '' ISO/IEC 25010:2011 - Quality in use characteristics and subcharacteristics'' </ref>]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process<br/><br />
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models<br />
<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering<br />
*http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method<br />
*http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems<br />
*http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
* B. S. Blanchard, W. J. Fabrycky - Systems Engineering and analysis 4th edition<br />
* K. Pohl - Requirements Engineering: Fundamentals, Principles and Techniques<br />
* G. Kotonya, I. Sommerville - Requirements Engineering - Processes and techniqes<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6946Requirements engineering2014-12-01T22:37:54Z<p>Joh: /* Functional requirements */</p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements<ref name="snow">["http://www.informit.com/articles/article.aspx?p=1929849&seqNum=15"] ''Snow Card Template - InformIT'' </ref>]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process<br/><br />
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models<br />
<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering<br />
*http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method<br />
*http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems<br />
*http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
* B. S. Blanchard, W. J. Fabrycky - Systems Engineering and analysis 4th edition<br />
* K. Pohl - Requirements Engineering: Fundamentals, Principles and Techniques<br />
* G. Kotonya, I. Sommerville - Requirements Engineering - Processes and techniqes<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6944Requirements engineering2014-12-01T22:37:23Z<p>Joh: /* Functional requirements */</p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements<ref name="Iso2011">["http://www.informit.com/articles/article.aspx?p=1929849&seqNum=15"] ''Snow Card Template - InformIT'' </ref>]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process<br/><br />
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models<br />
<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering<br />
*http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method<br />
*http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems<br />
*http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
* B. S. Blanchard, W. J. Fabrycky - Systems Engineering and analysis 4th edition<br />
* K. Pohl - Requirements Engineering: Fundamentals, Principles and Techniques<br />
* G. Kotonya, I. Sommerville - Requirements Engineering - Processes and techniqes<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6942Requirements engineering2014-12-01T22:34:42Z<p>Joh: /* Additional related material */</p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process<br/><br />
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models<br />
<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering<br />
*http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method<br />
*http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems<br />
*http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
* B. S. Blanchard, W. J. Fabrycky - Systems Engineering and analysis 4th edition<br />
* K. Pohl - Requirements Engineering: Fundamentals, Principles and Techniques<br />
* G. Kotonya, I. Sommerville - Requirements Engineering - Processes and techniqes<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6941Requirements engineering2014-12-01T22:34:15Z<p>Joh: /* Additional related material */</p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process<br/><br />
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models<br />
<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering<br />
*http://dl.acm.org/citation.cfm?id=545779 - System Requirements Engineering book<br />
*http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method<br />
*http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems<br />
*http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
* B. S. Blanchard, W. J. Fabrycky - Systems Engineering and analysis 4th edition<br />
* K. Pohl - Requirements Engineering: Fundamentals, Principles and Techniques<br />
* G. Kotonya, I. Sommerville - Requirements Engineering - Processes and techniqes<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6931Requirements engineering2014-12-01T22:30:36Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process<br/><br />
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models<br />
<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering<br />
*http://dl.acm.org/citation.cfm?id=545779 - System Requirements Engineering book<br />
*http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method<br />
*http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems<br />
*http://sutlib2.sut.ac.th/sut_contents/H104135.pdf - A book about Systems Engineering and Analysis, this book cover most of the system and requirement engineering process<br />
*http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.<br />
*http://dl.acm.org/citation.cfm?id=1869735 - Good book that covers the fundamentals of requirements engineering<br />
*http://www.saxo.com/dk/requirements-engineering_gerald-kotonya_hardback_9780471972082 - Also a good book that covers the fundamentals of requirements engineering with good techniques and methods.<br />
<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6929Requirements engineering2014-12-01T22:30:00Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008 - Systems and software engineering - System life cycle processes<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007 - Systems engineering -- Application and management of the systems engineering process<br/><br />
http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733 - ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models<br />
<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB - Video presentation about introduction to requirements engineering<br />
*http://dl.acm.org/citation.cfm?id=545779 - System Requirements Engineering book<br />
http://www.wohlin.eu/rm_chapter05.pdf - A paper about the context method<br />
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.365.8494 - A document specifying design and validation for software systems<br />
http://sutlib2.sut.ac.th/sut_contents/H104135.pdf - A book about Systems Engineering and Analysis, this book cover most of the system and requirement engineering process<br />
http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf - Paper about requirements elicitation.<br />
http://dl.acm.org/citation.cfm?id=1869735 - Good book that covers the fundamentals of requirements engineering<br />
http://www.saxo.com/dk/requirements-engineering_gerald-kotonya_hardback_9780471972082 - Also a good book that covers the fundamentals of requirements engineering with good techniques and methods.<br />
<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6884Talk:Requirements engineering2014-12-01T22:17:59Z<p>Joh: /* Strength and weaknesses */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
**'''''Fixed'''''<br />
<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''<br />
<br />
* '''''Thank your for your review, it was very helpfull and gave new perspective! :-)'''''<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
* '''''This should be fixed now, thanks highlighting that. :-)''''''<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''<br />
<br />
*'''''Thank you for your review, I can definitely see the language in the article has improved due to you catching my grammatical errors. :-) '''''</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6871Talk:Requirements engineering2014-12-01T22:15:13Z<p>Joh: /* General remarks */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
**'''''Fixed'''''<br />
<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''<br />
<br />
* '''''Thank your for your review, it was very helpfull and gave new perspective! :-)'''''<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
* '''''This should be fixed now, thanks highlighting that. :-)''''''<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6870Talk:Requirements engineering2014-12-01T22:14:42Z<p>Joh: /* General remarks */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
**'''''Fixed'''''<br />
<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''<br />
<br />
* '''''Thank your for your review, it was very helpfull and gave new perspective! :-)'''''<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
* ''''''This should be fixed now, thank highlighting that. :-)''''''<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6868Talk:Requirements engineering2014-12-01T22:13:39Z<p>Joh: /* Discussion */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
**'''''Fixed'''''<br />
<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''<br />
<br />
* '''''Thank your for your review, it was very helpfull and gave new perspective! :-)'''''<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6867Talk:Requirements engineering2014-12-01T22:13:26Z<p>Joh: /* Discussion */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
**'''''Fixed'''''<br />
<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''<br />
<br />
** '''''Thank your for your review, it was very helpfull and gave new perspective! :-)'''''<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6862Talk:Requirements engineering2014-12-01T22:12:22Z<p>Joh: /* Discussion */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
**'''''Fixed'''''<br />
<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
** '''''Hmm again I'm not to sure what you mean, but as said earlier I have reworked but the introduction and discussion part in order to make it a little more coherent'''''<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6850Requirements engineering2014-12-01T22:09:35Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011<ref name="Iso2011">["http://www.iso.org/iso/catalogue_detail.htm?csnumber=35733"] '' ISO/IEC 25010:2011 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models'' </ref> standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6848Talk:Requirements engineering2014-12-01T22:07:26Z<p>Joh: /* Non-functional requirements */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
** '''''I'm not exactly sure what you mean, but I have tried to elborate a little more on this section and provide examples'''''<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
**'''''Fixed'''''<br />
<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6843Talk:Requirements engineering2014-12-01T22:05:39Z<p>Joh: /* Requirements elicitation */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
**'''''Thank you - Well yes I could elaborate more on this, but a have ALOT of text in that section already. So I don't think it is necessary to cover this futher, as well as there is further reading material if one would be more interested in this method.'''''<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6838Talk:Requirements engineering2014-12-01T22:01:24Z<p>Joh: /* General remarks */</p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
** '''''I've have made my definition a little more clear, and redid some stuff in the intro part and discussion to make them more coherent.'''''<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6832Requirements engineering2014-12-01T21:59:05Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br/><br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering (RE) - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|The RE life cycle model - showing the methods covered in this wiki page, and the phases they belong to in the life cycle]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Context method example - An example of process on how to define requirements context]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow Card Template, a template on how to do functional requirements]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011 standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on selected qualites and attributes]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6802Requirements engineering2014-12-01T21:52:12Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About this wiki page'''<br />
A majority of this wiki page contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted that, if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one of the key components of every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where one of the challenges lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, in order to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. Because requirements can be very important if a project doesn’t go as intended, the requirements could potentially turn out to be the main evidence in a lawsuit. <br />
<br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996 on project failures, showed that reason for project failures falls in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introducing proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements (or needs).<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the fact that the <br />
methods of designing requirements are more developed and apply very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to fulfill a need – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify which kind of process paradigm that is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found in the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This wiki page will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|Method examples shown in the requirements engineering life cycle model]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found in the additional reading section.<ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. More information can be found in the section for additional reading material. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The method of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of system the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating functional requirements. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow card template]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in itself be pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exist quality lists that are made as standards, to help define systems. <br />
<br />
These lists exist as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011 standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities and attributes.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on chosen qualities ]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed in an implementation then it is very likely the system will be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying it’s functionality. It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort, control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest.<ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
This wiki page has only covered a bit, of the contents of requirements engineering. Requirements engineering is a huge topic with a lot of knowledge in defining various systems and provides great methods on how to structure and manage requirements that will satisfy stakeholder needs, through some of the methods explained in this wiki page. Hopefully this page has given an idea on how requirements engineering can be done, as well as give inspiration to someone who might consider doing some requirements engineering as part of a project. <br />
<br />
So why do requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6577Requirements engineering2014-12-01T20:34:46Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do and how it is going to do it. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. <br />
<br />
'''About the article'''<br />
A majority of this article contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted in that if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one the key components for every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where the challenge lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. The importance requirements is because if a project doesn’t go as intended, then the requirements could potentially be the main evidence in a potential lawsuit. <br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of the where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows that the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
In terms of management, requirements form the basis for:<br />
<br />
* Project planning<br />
* Risk management<br />
* Acceptance testing<br />
* Trade off<br />
* Change control<br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements.<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the methods of requirement being more developed and applies very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify what kind of process paradigm, which is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This article will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|Method examples shown in the requirements engineering life cycle model]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject.<br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found here: <ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes.<ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow card template]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in it self is pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exists quality lists to help define a system. <br />
<br />
These list exists as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011 standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on chosen qualities ]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
So why should one bother doing requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Talk:Requirements_engineering&diff=6503Talk:Requirements engineering2014-12-01T20:01:36Z<p>Joh: </p>
<hr />
<div>== Review by MrP ==<br />
<br />
==General remarks==<br />
*Very relevant topic, thorough and well researched article, with a lot of substance for the reviewer to work on :-)<br />
** '''''Thanks for the complement'''''<br />
*Good sample of references and links to other material<br />
** '''''Thanks'''''<br />
*You introduce a lot of (apparently cross- and interrelated) concepts, notions, phases etc in which the reader easily gets lost - And therefore sometimes misses your good points on how to conduct proper requirements assessment and definition <br />
** '''''I've tried to clear this up, hopefully I succeeded :-)'''''<br />
*Some general advice for improvement of the article: 1)Make it clearer for the reader if "requirements engineering" should be understood as a well defined discipline and a coherent standard method of practice resembling e.g. Systems engineering, or is it just a collective term for a set of useful tools ? 2) Consider making your introduction/abstract and discussion/conclusion a bit sharper and mutually coherent<br />
<br />
==Specific remarks==<br />
Below please find som specific remarks, adressing particular sections in your article<br />
<br />
===Introductory paragraph===<br />
*Second sentence: Are you referring to requirements as "formalities"? Difficult to understand.<br />
** '''''Ok, I might see what you mean. I have change the sentence a bit. The sentence is now: Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project.'''''<br />
*See also general remark, consider rephrasing the paragraph to set the scene for your article better<br />
** '''''I’m not sure i know what you mean be rephrasing the paragraph? Do your mean the section in general? if yes I have done extra work on it'''''<br />
<br />
===Application context===<br />
*First sentence: You write that requirements defines the stakeholders, users and customers - is it not the other way round ?<br />
** '''''Fixed - Reworked this section'''''<br />
*Second sentence: You state the importance of understanding the requirements "completely and unambiguously. That is probably the core of requirements management and requirements "engineering", therefore you should consider elaborating the statement at this point in the article, maybe referring to the section "Req. elicitation" later in the article<br />
** '''''Fixed - Reworked this section'''''<br />
*Sentences no. 8 and 9 are difficult to understand, consider rephrasing<br />
** '''''Fixed - Reworked this section'''''<br />
===Acceptance and use===<br />
*In general, this section (and even the header itself) is a bit difficult to understand.<br />
** '''''Fixed - I have gone over the entire section and reworked it. The headline is also been altered.'''''<br />
*As mentioned in the general remarks you indicate that "requirements engineering" is a defined discipline or process, but you do not elaborate on or describe it's definition<br />
** '''''Fixed'''''<br />
*What is the point of your references to software development issues in the first half of the paragraph?<br />
** '''''Fixed'''''<br />
*It is a good idea to give examples like the one of the railway system, but the point is difficult to grasp<br />
** '''''Fixed'''''<br />
<br />
===Creating requirements===<br />
*In this section you introduce a definition of "requirements engineering" as a Deming-type circular process. Is that correctly understood by the reader? -If so you should consider using the graphic representation more, elaborating on all 4 steps in the circle as they are named on the diagram. As the article is written now it is difficult to see the connection between the "RE Lifecycle" and the issues you elaborate on in the following sections.<br />
** '''''Fixed - I’ve tried to elaborate a little more on requirement lifecycle and I tried to explain it better.'''''<br />
<br />
===Major concepts===<br />
You should consider deleting this header, it does not contribute to the reader's overview of the article, as long as you don't show a coherent whole framework for those "concepts"<br />
* '''''Fixed - I have deleted this headline, you are right is does not really contribute with anything'''''<br />
<br />
===Requirements elicitation===<br />
*This is an interesting section, apparently introducing learning and skills from the domain of psychology into the world of "engineering". The human factor ! It would be even more interesting if you could elaborate on this "shift of mindset" a bit more, and maybe reflect on how an engineering or project management practitioner can apply these methods in his practice, in particular how to handle the "translation" of the "elicitated requirements" into engineering specifications<br />
<br />
===Design and validation===<br />
*It becomes a little unclear where we are now in the RE lifecycle?<br />
** '''''I have made a Requirement Life Cycle section that hopefully has cleared that up. :-)'''''<br />
===Context===<br />
*You refer to this item as a "phase", bur for the reader it is very unclear where in your RE lifecycle this phase belongs. The considerations you mention in this section is probably clever and relevant, but the reader is lost at this point.<br />
** '''''Fixed'''''<br />
===Functional requirements===<br />
*Again you refer to this as a "phase in requirements engineering". What phase in what model? I'm afraid many readers would be lost at this point.<br />
** '''''Fixed - I have made it different, I now refer to it as a method, see requirement life cycle'''''<br />
*If you believe the snow card is an good example of an applicable method you should consider showing a larger and readable picture, and to explain and elaborate on it. Otherwise don't show it.<br />
** '''''Fixed - I have made the picture bigger'''''<br />
===Non-functional requirements===<br />
*Your definition of non-functional requirements as "qualities" is interesting, you should consider giving some (authoritative?) references to this definition.<br />
*You should give the source reference for your list of "qualities", it is unclear if the list comes from the ISO standard mentioned - also unlisted in the references.<br />
===Requirements management===<br />
*Again you denote this as a "phase" - however this time I believe that we are back on the previously shown RE lifecycle again ?. You should consider explaining to the reader how these "management" (your own denotion) processes you describe here corresponds with the "engineering" processes of your RE lifecycle. Is "Requirement Management" an element or a process within Requirements engineering ?<br />
** '''''Fixed'''''<br />
===Discussion===<br />
*It seems to this reviewer that in this section you just repeat your arguments from the "Background" introduction for particular effort on requirements engineering in project work. Consider instead to make some application advice or reflections on the practices and methods you have described, e.g. describe a link between your "requirements engineering" and project management standard practices.<br />
<br />
== Review by TigR ==<br />
<br />
==General remarks==<br />
<br />
<br />
;Language<br />
:Some minor things, mainly grammatical; like using "the" in front of customer* and some phrases become "Speech" instead of written text.. see details in specific remarks.<br />
;Layout<br />
:Be attentive of how your final article looks, use preview to make sure that what you have written is also displayed in that way.. I have found that sometimes an extra "enter" is needed to convince wiki to give me the next line. Also, start your headers from level 2 '==' as level 1 is reserved the title of your page (according to the [http://www.mediawiki.org/wiki/Help:Formatting Help page on formatting])<br />
<br />
==Specific remarks==<br />
<br />
===Introduction===<br />
;Grammatical things<br />
:"among ''the'' involved parties"<br />
*'''''Fixed'''''<br />
:"from a client" => "''of'' a client"<br />
*'''''Fixed'''''<br />
:"goal of the product" can a product have "goals" I've heard of projects with goals.. I may be wrong here.<br />
*'''''Fixed'''''<br />
:"the developers ''create''" developers can be replaced with 'they' and "they creates" is incorrect (it's a good test to do if it sounds off, change to one of the known words ''I, you, he/she/it, we, You, they'' :)<br />
*'''''Fixed - I’ve put in ‘Developers create’, otherwise in my opinion it creates a little confusion on who I’m talking about if I put in ‘They’'''''<br />
:"to specific" => "to ''specify''"<br />
*'''''Fixed'''''<br />
:"is suppose" => "is ''supposed''"<br />
*'''''Fixed'''''<br />
:"the basis to get" => "the basis ''for getting''"<br />
*'''''Fixed'''''<br />
:"a iterative" => "''an'' iterative" the usual test for a and an is checking the first letter of the word following it; is it a vowel then it is ''an'' <br />
*'''''Fixed'''''<br />
:"reflect a product best possible" not sure exactly what is meant here, but I will guess rearranging it to "reflect the best possible product" gives the correct meaning.<br />
*'''''Fixed'''''<br />
The introduction is (besides the above stuff) very well written and explanatory.<br />
*'''''Thanks :-)'''''<br />
<br />
===Background===<br />
due to the header it is difficult to see that the text is an introduction to the following sub-headers..<br />
*'''''I have also removed it, thanks for noticing'''''<br />
===Application context===<br />
;Grammatical things<br />
:"basis for" => "basis ''of''"<br />
*'''''Fixed'''''<br />
:"and that is where" => "and ''this'' is where"<br />
*'''''Fixed'''''<br />
:"to understand" => "''understanding''"<br />
*'''''Fixed'''''<br />
:"''the'' need", "''the'' problem"<br />
*'''''Fixed'''''<br />
:"is done" => "is ''reached''" or "''has been established''"<br />
*'''''Fixed'''''<br />
:"need of" => "need ''for''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"be clear defined" => "be ''clearly'' defined"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"It is about" <= speech, and what is ''It'' in this sentence?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"creating stable" => "creating ''a'' stable"<br />
*'''''Fixed'''''<br />
:"the destination" <= I think "where you might end" sounds a bit better?<br />
*'''''Fixed'''''<br />
:I'd scrap "though" and start at "The intention of ''the'' requirements"<br />
*'''''Fixed'''''<br />
:you mix times.. "is" and "would".. use "will"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"management requirements" ? missing a komma? and then "form" without s<br />
*'''''Fixed'''''<br />
:"There exists multiple examples" => "''Multiple examples exist''"<br />
*'''''Fixed'''''<br />
:"because poorly" => "because ''of'' poorly"<br />
*'''''Fixed'''''<br />
:"shows the problems" => "shows ''that'' the problems"<br />
*'''''Fixed'''''<br />
:perhaps use ":" to list the three categories?<br />
<br />
Perhaps elaborate bit more about the challenge you mention<br />
*'''''Fixed - I have elaborated a little bit and given an example :-)'''''<br />
<br />
===Acceptance and use===<br />
;layout<br />
:a big text like this one can be heavy to take in one chunk.. if you insert more "enter" or I guess in english you call them "breaks" or "new line" you can force the text into sections which are easier to read.<br />
*'''''Fixed'''''<br />
<br />
;Grammatical things<br />
:"requirement''s'' engineering"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"dominant force of change of products" <= needs some rephrasing to display the actual meaning clearly.<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"the could cause" => "''this'' could cause ''a''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"Even though" be careful with starting off sentences like that if they stand alone, "on the other hand" might be what you mean.. or you could just decide to state it as "Requirements engineering can be..".<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"for example" => "for example'';''"<br />
*'''''Fixed'''''<br />
:again "requirement''s'' engineering" be consistent in that one, not mentioning it again.<br />
*'''''Fixed'''''<br />
:"applies" => "''also'' applies"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:try to read the sentence without the insert.. "components which.." consider revision of the last part.<br />
*'''''Fixed'''''<br />
:"There exist several standards" => "''Several standards exist''"<br />
*'''''Fixed - The sentence has changed, so I’ve chosen to go with what is says now.'''''<br />
:"define''.''" and "where in" => "''In''"<br />
*'''''Fixed'''''<br />
:"likely the" => "likely ''that'' the"<br />
*'''''Fixed'''''<br />
Interesting and with substance<br />
*'''''Thank you :-)'''''<br />
===Creating requirements===<br />
;Layout<br />
: remember the header issue<br />
*'''''Fixed - Renamed the header and fixed the issue regarding level of headlines.'''''<br />
;Grammatical things<br />
:"different ways" <= perhaps add an indicator of ammount? several, many, some.<br />
*'''''Fixed - I have elaborated a little more on which ways im talking about. So i think it’s not necessary to put an amount on it.'''''<br />
:"accordingly" => "according"<br />
*'''''Fixed'''''<br />
:"a system" => "''the'' system" ?<br />
*'''''Fixed'''''<br />
:"suppose''d''"<br />
*'''''Fixed'''''<br />
:"achieve ''the''"<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:"best as possible." => "the best." ?<br />
*'''''Fixed - Removed words while redoing section'''''<br />
:ouch.. missing the ''s'' in your text for the picture as well.<br />
*'''''Fixed'''''<br />
:"in this article".... are they? which article.. the one I'm reading or the one you are referring to?<br />
*'''''Fixed'''''<br />
<br />
===Major concepts===<br />
no intro?<br />
*'''''Fixed - removed header, didn't really add anything :-)'''''<br />
<br />
===Requirements elicitation===<br />
;Layout<br />
:Again a very large chunk of text.. try to divide it, perhaps using the same scheme as I do with ";The objective technique:" next line ":The objective technique is..." use the preview function to make it look readable and structured.<br />
:Beautiful table. well thought.<br />
*'''''Thank you'''''<br />
<br />
;Grammatical things<br />
:req-''s'' again.. is the header or text incorrect?<br />
*'''''Fixed - In this case it would be the text. '''''<br />
:"to understanding" => "to understand"<br />
*'''''Fixed'''''<br />
:take out "Though"<br />
*'''''Fixed'''''<br />
:"use full" => "useful"<br />
*'''''Fixed'''''<br />
:"for which the requirements need to fulfill" ? the requirements have to fulfill the surrounding environment?<br />
*'''''Fixed - Wups, seems like I have made a double sentence there. Nice spottet, thanks!'''''<br />
:"called more like a" speech language => "called a"<br />
*'''''Fixed'''''<br />
:"where some like" => "where some''thing'' like"<br />
*'''''Fixed'''''<br />
:"in to" => "into" (best test.. make the space a deliberate pause when reading)<br />
*'''''Fixed'''''<br />
:"desire''s''"<br />
*'''''Fixed'''''<br />
:"t''h''rough"<br />
*'''''Fixed'''''<br />
<br />
impressive chapter, very few errors and very understandable.<br />
*'''''Thanks :-)'''''<br />
<br />
===Design and validation===<br />
;Grammatical things<br />
:"minded for" => "minded ''towards''"<br />
*'''''Fixed'''''<br />
:"intention" => "intent"<br />
*'''''Fixed'''''<br />
:"phase'',''"<br />
*'''''Fixed'''''<br />
:"useful to" => "useful ''for''"<br />
*'''''Fixed'''''<br />
:"fulfills ''the''"<br />
*'''''Fixed'''''<br />
good<br />
<br />
===Context===<br />
;Grammatical things<br />
:"most reflect" => "most''ly'' reflect"<br />
*'''''Fixed'''''<br />
:"the project has" => "of the project"<br />
*'''''Fixed'''''<br />
:"establishing context"<br />
*'''''Fixed'''''<br />
:"identifying systems or process''es''"<br />
*'''''Fixed'''''<br />
<br />
only minor stuff<br />
<br />
===Functional requirements===<br />
;Grammatical things<br />
:"on''e''"<br />
*'''''Fixed'''''<br />
:"meanwhile" => "while"<br />
*'''''Fixed'''''<br />
:"''in order'' to leave out any doubt ''regarding'' the goal of the requirement."<br />
*'''''Fixed'''''<br />
:"exits" => "''exist''"<br />
*'''''Fixed'''''<br />
:"uses cases" => "use''r'' cases"?<br />
*'''''Fixed - It’s actually suppose to say use cases. It is a technical term.'''''<br />
:"in the picture below" <= but I see it above or besides the text?<br />
<br />
the picture is fairly small if you were to see the idea of it without clicking on it.<br />
*'''''Fixed'''''<br />
<br />
===Non-functional requirements===<br />
;Grammatical things<br />
:Whoa.. "Quality means..." that sentence needs some serious rework.. think about what it means as it is written now.<br />
*'''''Fixed - Redid section, so hopefully it makes more sense now.'''''<br />
:"irrespective"? => "regardless"<br />
*'''''Fixed'''''<br />
:"specify a some" ?<br />
*'''''Fixed'''''<br />
:"There exits ISO standards" => "ISO standards exi''st''"<br />
*'''''Fixed - Sentence has been reworked'''''<br />
:"The idea is then" => "The procedure is"<br />
*'''''Fixed'''''<br />
:"system goal''s''"<br />
*'''''Fixed'''''<br />
:"argument ''of''"<br />
*'''''Fixed'''''<br />
:"example on list of" => "example ''of a'' list ''with''"<br />
*'''''Fixed'''''<br />
<br />
Perhaps (if possible) move the picture to the right of the text<br />
*'''''Fixed - I have made the picture bigger and larger in the left side. It's a little hard to control in the right side'''''<br />
<br />
===Acceptance test===<br />
;Grammatical things<br />
:"engineering disciplines" => "engineering discipline"<br />
*'''''Fixed'''''<br />
:"various way''s''" & "testing ''a'' system"<br />
*'''''Fixed'''''<br />
:"should consists" => "should consist" or "consists"<br />
*'''''Fixed'''''<br />
<br />
===Requirements management===<br />
;Grammatical things<br />
:"activates" ? => "activities"?<br />
*'''''Fixed'''''<br />
:"in ''a'' more"<br />
*'''''Fixed'''''<br />
:"exi''st''" ok, think of it this way.. exit_, a way out, or more with s.. exist, is present<br />
*'''''Fixed'''''<br />
<br />
===Discussion===<br />
;Grammatical things<br />
:"exi''st''"<br />
*'''''Fixed'''''<br />
:if you haven't already, search and replace all "requirement engineering" with "requirements engineering"<br />
*'''''Fixed'''''<br />
:"size''s''"<br />
*'''''Fixed'''''<br />
:"computers systems" => "computer systems"<br />
*'''''Fixed'''''<br />
:"systems ''have''" as in they have<br />
*'''''Fixed'''''<br />
:"affect" => "effect" verb vs. noun<br />
*'''''Fixed'''''<br />
:"for everyday" => "for every day"<br />
*'''''Fixed'''''<br />
:"consequence''s''"<br />
*'''''Fixed'''''<br />
:"why today the .... quality" => "why the .... quality today"<br />
*'''''Fixed'''''<br />
:"be emphasize the" => "be emphasize''d that''"<br />
*'''''Fixed'''''<br />
:"solution by" => "solution ''in''"<br />
*'''''Fixed'''''<br />
:"every persons" => "every person"<br />
*'''''Fixed'''''<br />
<br />
===Strength and weaknesses===<br />
;Grammatical things<br />
:"as wells" => "as well"<br />
*'''''Fixed'''''<br />
:"Though that the fact .... same" => "The fact .... same though"<br />
*'''''Fixed'''''<br />
:"benefit of ''using''"<br />
*'''''Fixed'''''<br />
:"and ''generate'' higher"<br />
*'''''Fixed'''''<br />
:"contribution''s''"<br />
*'''''Fixed'''''<br />
:"Though it is" => "It is"<br />
*'''''Fixed'''''<br />
:"but it is" => "but"<br />
*'''''Fixed'''''</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6413Requirements engineering2014-12-01T19:23:44Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do and how it is going to do it. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. Requirements engineering is considered an iterative process, so the requirements will reflect the overall system best as possible.<br />
<br />
'''About the article'''<br />
A majority of this article contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted in that if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one the key components for every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where the challenge lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. The importance requirements is because if a project doesn’t go as intended, then the requirements could potentially be the main evidence in a potential lawsuit. <br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of the where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows that the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
In terms of management, requirements form the basis for:<br />
<br />
* Project planning<br />
* Risk management<br />
* Acceptance testing<br />
* Trade off<br />
* Change control<br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements.<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the methods of requirement being more developed and applies very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify what kind of process paradigm, which is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|500px|none|Requirements Engineering - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This article will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
[[File:RELifeCycleExample.jpg|thumb|500px|none|Method examples shown in the requirements engineering life cycle model]]<br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject.<br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found here: <ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes.<ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
[[File:SnowCard.jpg|thumb|500px|none|Snow card template]]<br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in it self is pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exists quality lists to help define a system. <br />
<br />
These list exists as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011 standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities.<br />
<br />
[[File:Qualities.jpg|thumb|none|300px|Example on chosen qualities ]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
So why should one bother doing requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6366Requirements engineering2014-12-01T19:03:09Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do and how it is going to do it. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. Requirements engineering is considered an iterative process, so the requirements will reflect the overall system best as possible.<br />
<br />
'''About the article'''<br />
A majority of this article contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. In this wiki page it should be noted in that if a reference is in the end of a section, then it refers to the whole section. <br />
<br />
== Application context == <br />
Requirements are one the key components for every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where the challenge lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. The importance requirements is because if a project doesn’t go as intended, then the requirements could potentially be the main evidence in a potential lawsuit. <br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of the where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
In terms of management, requirements form the basis for:<br />
<br />
• Project planning<br />
• Risk management<br />
• Acceptance testing<br />
• Trade off<br />
• Change control<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows that the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements.<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the methods of requirement being more developed and applies very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify what kind of process paradigm, which is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|right|Requirements Engineering - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This article will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
<br />
* Ideation & Elicitation <br />
** Requirements elicitation<br />
* Elaboration<br />
** Design and validation<br />
** Context<br />
** Functional requirements<br />
** Non-functional requirements<br />
* Validation<br />
** Acceptance test<br />
* Management<br />
** Requirement Management <br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. ************<br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found here: <ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes.<ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right|Snow card template]]This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in it self is pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exists quality lists to help define a system. <br />
<br />
These list exists as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011 standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities.<br />
<br />
[[File:Qualities.jpg|thumb|none|Example on chosen qualities ]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
So why should one bother doing requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Reference =<br />
<references /><br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]<br />
[[Category:Risk Management]]<br />
[[Category:Requirements Management]]</div>Johhttp://13.50.150.85/index.php?title=File:RELifeCycleExample.jpg&diff=6353File:RELifeCycleExample.jpg2014-12-01T19:00:51Z<p>Joh: </p>
<hr />
<div></div>Johhttp://13.50.150.85/index.php?title=File:LifeCycle.jpg&diff=6350File:LifeCycle.jpg2014-12-01T18:59:22Z<p>Joh: Joh uploaded a new version of &quot;File:LifeCycle.jpg&quot;</p>
<hr />
<div></div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6288Requirements engineering2014-12-01T18:33:29Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do and how it is going to do it. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. Requirements engineering is considered an iterative process, so the requirements will reflect the overall system best as possible.<br />
<br />
'''About the article'''<br />
A majority of this article contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. So if a reference is in the end of a section, then it means that the book references to the whole section. <br />
<br />
== Application context == <br />
Requirements are one the key components for every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where the challenge lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. The importance requirements is because if a project doesn’t go as intended, then the requirements could potentially be the main evidence in a potential lawsuit. <br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of the where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
In terms of management, requirements form the basis for:<br />
<br />
• Project planning<br />
• Risk management<br />
• Acceptance testing<br />
• Trade off<br />
• Change control<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows that the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements.<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the methods of requirement being more developed and applies very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify what kind of process paradigm, which is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|right|Requirements Engineering - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This article will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
<br />
* Ideation & Elicitation <br />
** Requirements elicitation<br />
* Elaboration<br />
** Design and validation<br />
** Context<br />
** Functional requirements<br />
** Non-functional requirements<br />
* Validation<br />
** Acceptance test<br />
* Management<br />
** Requirement Management <br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. ************<br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found here: <ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes.<ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right|Snow card template]]This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in it self is pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exists quality lists to help define a system. <br />
<br />
These list exists as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011 standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities.<br />
<br />
[[File:Qualities.jpg|thumb|none|Example on chosen qualities ]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
So why should one bother doing requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
== Comparable standards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br/><br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=6285Requirements engineering2014-12-01T18:30:30Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. <br />
Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do and how it is going to do it. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. Requirements engineering is considered an iterative process, so the requirements will reflect the overall system best as possible.<br />
<br />
'''About the article'''<br />
A majority of this article contents comes from books mention in reference and material the author has learned from the course no. 02264 – Requirements engineering at DTU Compute. So if a reference is in the end of a section, then it means that the book references to the whole section. <br />
<br />
== Application context == <br />
Requirements are one the key components for every project, they describe stakeholders such as users, customers, suppliers, etc. and their needs for potential new system. In order to understand all involved parties, requirements are generally expressed in natural language and this is where the challenge lies. The challenge is to make sure all parts of requirements engineering are expressed and documented in a precise and formal manner, to create mutual understanding and leave out any misunderstanding or confusion among the stakeholders. The importance requirements is because if a project doesn’t go as intended, then the requirements could potentially be the main evidence in a potential lawsuit. <br />
So once an agreement between all involved parties is reached, then the requirements will drive the project activity. Though through the project, the stakeholder may introduce new needs or features they want, and often the reasons why they do that is the requirements not being properly defined from the beginning or the needs is not being properly understood by the developers. Requirements engineering is about creating a mutual starting point between the stakeholder and the developer, thereby creating a stable requirements base. It is the same as, imagining a project being like setting off on journey without any idea of the where you might end. But with requirements, you would have a map of that journey, so you would at all times know where you’re headed.<br />
<br />
In terms of management, requirements form the basis for:<br />
<br />
• Project planning<br />
• Risk management<br />
• Acceptance testing<br />
• Trade off<br />
• Change control<br />
<br />
Multiple examples exist on how project failures occurred because of poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows that the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
Today one of the key success factors in the global competitive market is fulfilling stakeholder requirements.<br />
This key success factor can be managed by systems engineering, and that is why systems engineering is crucial in the industry. Requirements engineering is an important stage of systems engineering and it’s overall process. It helps create control and structure in the process of developing a system. <br />
<br />
Over the years the discipline of requirements engineering is most often seen in software engineering, due to the methods of requirement being more developed and applies very well to the process of developing software. But requirements engineering can be applied across engineering disciplines, the basic principles and practice will also work on other systems than software.<br />
For example, consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min. Satisfaction of that high-level requirement arises from every major component in the system being able to interact and work as indented. In this example those components could for example be: The trains, the railway infrastructure, traffic system or the tracks ability to support high-speed trains, etc.<br />
The point is that requirements engineering applies to all systems. Where the system in this example should be understood as a collection of components – machine, infrastructure or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
<br />
Today there exist several standards on how to manage and use requirements engineering in the industry, where one standard could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define. Where in some cases it will be likely that the requirements will deviate from the standards. But that’s also okay, as long as it makes sense for the system being defined.<ref name="REBOOK" /><br />
<br />
== Requirement lifecycle ==<br />
Requirements engineering is tricky as it can be done in different ways, the idea is to form the requirements according to what the system is supposed to do. The first important step is to determine or identify what kind of process paradigm, which is used in the development of a system. There exist various known process models such as the V-Model, Waterfall model, the spiral model, agile, etc. A common element among every process model is that they all use the same requirement lifecycle as it is shown in the picture.<br />
[[File:LifeCycle.jpg|thumb|right|Requirements Engineering - life cycle model]]<br />
The reason why the process paradigm needs to be identified is because they all use the requirement life cycle in different ways. <br />
For example, the waterfall model will only visit each phase in the requirement lifecycle once, one after the other. Where in an agile process it will go through the requirement life cycle, each time there is a new iteration. More information about these process paradigms and there relation to the requirement lifecycle can be found the two books: Requirements Engineering 3rd edition and Software Requirements both mentioned in the reference.<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
This article will go trough an example on how to use the requirement lifecycle, and show some examples on the most commonly used methods for each phase in the requirements life cycle.<br />
<br />
This wiki page will cover the following selected methods for each phase of the requirement lifecycle:<br />
<br />
* Ideation & Elicitation <br />
** Requirements elicitation<br />
* Elaboration<br />
** Design and validation<br />
** Context<br />
** Functional requirements<br />
** Non-functional requirements<br />
* Validation<br />
** Acceptance test<br />
* Management<br />
** Requirement Management <br />
<br />
=== Requirements elicitation ===<br />
Requirements elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
<br />
The '''objective technique''' is to understand as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any useful information.<br />
<br />
The '''observational technique''' is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
<br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. ************<br />
<br />
The '''introspective technique''' should be called a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where something like everyday activities as well as physical actives can lead us into daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desires or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming through a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
=== Design and validation ===<br />
This method might be more minded towards software development, but its intent can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this method is to elicit and validate requirements through interaction design. It should be stressed that in this method, one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful for validating the design, and securing that the design and requirements fulfills the purpose of the system. More information about design and validation can be found here: <ref name="SWBOOK" /> <br />
<br />
=== Context ===<br />
The context method is about setting the scene for the system through requirements. This method is about establishing the surrounding environment for the system, and describing the influence it will have. To do that, means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the system. Other possible relevant findings could be identifying systems or processes that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes.<ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right|Snow card template]]This is among one of the most important methods in requirements engineering. It is the method where the functional requirement for the system is being identified, and documented. It is important that one should take their time while being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt regarding what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exist various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, use cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
===Non-functional requirements===<br />
In this method we define the non-functional requirements of the system, which is also known as a qualities in the context of requirements. Quality is considered properties a system should have, thereby meaning a property that does not affect the core functionality of the system. For example, if the system would be computer, then one quality could for example be that the computer should be reliable. <br />
Defining quality like that can in it self is pretty broad, and could mean different things, that’s why it is also important to specify the quality attributes. Quality attributes is a set of attributes that helps understanding how to achieve the quality. So if we take the computer example again, the quality attributes of reliable could be: error tolerant, consistent and simple. Defining qualities and its attributes are hard and complex to define precisely. That’s why there exists quality lists to help define a system. <br />
<br />
These list exists as ISO standards listing certain qualities and its attributes, one example could be the ISO/IEC 25010:2011 standard. The procedure is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goals will only strengthen the argument of why they should be applied to the system. The picture shows an example of a list with selected qualities.<br />
<br />
[[File:Qualities.jpg|thumb|none|Example on chosen qualities ]]<br />
<br />
The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, regardless of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. It can be tempting to specify the qualities in detail, but that might exclude better solutions at the given moment.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
=== Acceptance test ===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering discipline, there are various ways of testing a system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consist of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
=== Requirement Management ===<br />
This method encompasses the overall process of requirements engineering, with a focus on management rather than engineering activities. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in a more simple way. There exist a long list of different tools, among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
== Discussion ==<br />
So why should one bother doing requirements engineering? Today systems exist everywhere where we go and where we are. Systems come in different shapes and sizes, for example many consumer devices and appliances are often computer systems, where other systems might be vehicles or engines. <br />
So systems have an influence and an effect on our every day, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequences ranging from minor inconveniences to a global disaster.<br />
That’s why the most cost-effective way to achieve better quality today is through requirements engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasized that the requirements engineering is not a solution in itself, but rather that a solution will contain requirements in some form. Therefore every person involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
=== Strength and weaknesses ===<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as well as being the main reason for failure. <br />
The fact still remains the same though, the benefit of using requirements engineering to prevent faults and generate higher quality in systems, is one of its single largest contributions. It is time consuming, but cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=4902Requirements engineering2014-11-29T15:20:23Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is a discipline in developing requirements for a system. Often, if a project is about creating a new system, then requirements are made to specify the system, in order to create common understanding among the involved parties in a project. Requirements specify the needs and conditions of a client to help developers understand the need they are fulfilling and how they should satisfy that need. Developers create the requirements on the basis of the needs, to specify what the product is supposed to do and how it is going to do it. Requirements engineering is regarded as crucial in a development process, because the outcome often creates the basis for getting financial support. It’s basically the formal link between stakeholders and developers. The requirements can be created either by the stakeholder who wants something built, as well as it can be the developer’s responsibility. Requirements engineering is considered an iterative process, so the requirements will reflect the overall system best as possible.<br />
<br />
== Application context == <br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management. <ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <ref name="REBOOK" /><br />
<br />
= Creating requirements =<br />
[[File:LifeCycle.jpg|thumb|right|Requirement Engineering - life cycle model]]Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system best as possible.<ref name="REBOOK" /><ref name="SWBOOK" /> The overall requirement life cycle in shown in the picture on the right.<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here. <ref name="SWBOOK" /> <br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right|Snow card template]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. <ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/> The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none|Example on chosen qualities ]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weaknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Talk:Stakeholders_from_a_dynamic_and_network_perspective&diff=3448Talk:Stakeholders from a dynamic and network perspective2014-11-25T21:11:41Z<p>Joh: /* Review by joh */ new section</p>
<hr />
<div>== JEPO Review ==<br />
<br />
=General Comments=<br />
* To Short<br />
* Not enough proper references<br />
* Would be nice with some pictures of the different stakeholder diagrams<br />
* Bullet point would make the reading a bit more easy and the main points of your article more visible<br />
<br />
=Abstract=<br />
* A long description of the over all topic. My be shorten it down to the different methods.<br />
* Could it be a good idea to pinpoint the different messages and recalling the problems which can appear? <br />
* List of typical failures of stakeholder analysis, could maybe be a good introduction and the need to create better awareness how to use the tool.<br />
<br />
=Overview of a Stakeholder Analysis=<br />
* Illustrations of on what levels a SA can be used<br />
* Maybe also a process diagram or bullet points of the procedure <br />
<br />
=Current practices=<br />
*What question do you have to make to identify the stakeholders.<br />
*What subgroups are their.<br />
*How to handle the different stakeholders?<br />
<br />
=What is missing=<br />
* This could maybe be included in the abstract?<br />
* What is the reason that people are not using the SA during the project time?<br />
* Maybe investigate, what is needed to make it happen. Break routines, establish awareness, integrate in monthly meetings?<br />
<br />
== Review by joh ==<br />
<br />
=== General comments ===<br />
Interesting topic, and seems relevant for project, program and portfolio management. Content wise it looks like you’re on the right path.<br />
Your writing skills also seems good, I don’t have any major comments in regards to the grammar or spelling.<br />
I’m assuming the article is still under development.<br />
<br />
* Your article is rather short, some concrete example on to do stakeholder analysis from the chosen perspective would be nice, and it would add some more content in the article<br />
* It might also be a good idea to clarify a little better if the topic is related to, either project, program or portfolio management or all of them. <br />
* Your content really needs some visualized support in the form of models, charts or tables; it would help much more on the general understanding.<br />
* Looks like references are present in the text in some kind of special form e.g [1, p.241], what does that mean? And where can I find the source?<br />
* References are missing in the bottom, but I’m assuming it is on its way.<br />
* If you have not done so, I would recommend going through the slides from lecture 19 from slide 6, as inspiration to structure your article better, because it seems a little messy now and missing a logical flow.<br />
<br />
=== Abstract ===<br />
* There is a lot of text in the abstract, I would consider using some parts of the abstract else where in the article and boil it down in the abstract.<br />
* If the is as it should be, I would recommend reading through it a couple of times in making sure there is a more fluent transitions between each areas being addressed in this section. <br />
* You use a lot of “ “ e.g. “knowledge of the project”, “seniority”, “involvement of the project”. What does that mean?<br />
<br />
=== Overview of a stakeholder analysis today ===<br />
* A graphical overview would really be nice here.<br />
* You go quite quickly into something specific, I thought this section was supposed to provide an overview? <br />
<br />
=== Current practices, when conducting a stakeholder analysis ===<br />
* I guess this text goes to some kind of model? Would be nice to see it?<br />
* Also a better transition from the overview of a stakeholder analysis today section to this section is recommended. As a reader, I don’t understand what is going on.<br />
<br />
=== What is missing ===<br />
* Again, a transition to this section is missing. I’m lost? In which context are we talking?<br />
* I think behavior is spelled behavior</div>Johhttp://13.50.150.85/index.php?title=Talk:Group_Dynamics_and_Personality_Types&diff=3378Talk:Group Dynamics and Personality Types2014-11-25T19:58:12Z<p>Joh: /* Review by joh */ new section</p>
<hr />
<div>== Review by joh ==<br />
<br />
=== Review of the content ===<br />
General comment: The academic level and quality of the content, seems to me to be quite good. I understand what the article is describing about group dynamics and personality types - it goes quite good through what the terms mean, and in which context they are relevant. It seems relevant especially for project management. If nothing else mentioned here in my review, then it is safe to assume I don’t have a comment or I think it’s fine.<br />
<br />
* Though I seem to miss a clear link between these two elements. Because I know how to find right personalities and I know how a group dynamic should be, but how would I know to put which personality into a group to give a certain dynamic? <br />
* If possible, more visual illustrations might good especially in the group sections, because the text now seems quite dense. <br />
* I guess a summary/abstract and a discussion is to come? <br />
<br />
=== Review of formal aspects ===<br />
The article is really taken shape in a good way, though it still looks like work in progress. But keep up the good work! <br />
<br />
* In section introduction: behaviour -> behavior<br />
* In section introduction: Sentence: their expertise, but on behalf of the individual profiles and behaviour. -> their expertise, but also on behalf of the individual profiles and behaviour.<br />
* In section introduction: Sentence: Furthermore will this it explain the different personality types based on the theory -> Furthermore this will explain the different personality types based on the theory<br />
* In section introduction: Senctence: To manage temporary project groups effectively, is it important to understand the group members, the behaviour, how group are developing and how the members are interacting with each other. -> ?? (I’m a little unclear on what this sentence is suppose to say)<br />
* In section introduction: missing reference to Carl Jung and Myers Briggs in the bottom. <br />
* In section Groups and Group Processes: organisation -> organization. (Do you use UK or US English, I would recommend stiking to the one or the other? Because in other place I’ve seen you spell organize, with a z.)<br />
* In section Groups and Group Processes: sentence: the communication between the group members, as they interact in seeking to find a solution -> the communication between the group members, as they interact in seeking an solution (removing three words, and adding one)<br />
* In section Group Dynamics: behaviour -> behavior<br />
* In section Group Dynamics: sentence: This article is therefore explaining the development of a group on behalf Tuckmans theory, and clarify -> This article is therefore explaining the development of a group on behalf Tuckmans theory, and clarifies<br />
* In section Group Development: behaviour -> behavior<br />
* In section Group Development: Model: missing model caption<br />
* In section Myers-Briggs Type Indicator – MBTI: organisation -> organization<br />
* In section Myers-Briggs Type Indicator – MBTI: analysing -> analyzing <br />
* In section Myers-Briggs Type Indicator – MBTI: connestions -> connections <br />
* In section Myers-Briggs Type Indicator – MBTI: tp -> to<br />
* In section Myers-Briggs Type Indicator – MBTI: 4 letter -> four letter<br />
* In section the 16 MBTI types: behaviour -> behavior<br />
* In section the 16 MBTI types: sentence: The table below are reflecting -> The table below is reflecting<br />
* In section the 16 MBTI types: in table: Counsellor -> Counselor <br />
* In section the 16 MBTI types: in table: Indipendent -> Independent<br />
* In section the 16 MBTI types: in table: Sceptical -> Skeptical<br />
* In section benefits of MBTI: sentence: The tool, helps people easily understand -> The tool helps people easily understand (no comma)<br />
* In section benefits of MBTI: Career conseling -> Career counseling<br />
* Headline of Diskussion of usability section shoud be Discussion of usability <br />
* General: All reference should be the bottom (I guess that is to come, you have already set some reference in the test, you are only missing to specify “<reference/>” in the bottom in the section reference, and the references will afterwards appear by them selves.) <br />
* General: Remember model/picture captions<br />
* General: Remember all places in text that points to a figure actually point to a figure and not only X</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2907Requirements engineering2014-11-25T00:33:48Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context == <br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management. <ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <ref name="REBOOK" /><br />
<br />
= Creating requirements =<br />
[[File:LifeCycle.jpg|thumb|right|Requirement Engineering - life cycle model]]Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system best as possible.<ref name="REBOOK" /><ref name="SWBOOK" /> The overall requirement life cycle in shown in the picture on the right.<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here. <ref name="SWBOOK" /> <br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right|Snow card template]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. <ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/> The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none|Example on chosen qualities ]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weaknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2906Requirements engineering2014-11-25T00:30:56Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context == <br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management. <ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005<ref name="Iso2005">["http://standards.ieee.org/findstds/standard/1220-2005.html"] ''1220-2005 - IEEE Standard for Application and Management of the Systems Engineering Process'' </ref>. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <ref name="REBOOK" /><br />
<br />
= Creating requirements =<br />
[[File:LifeCycle.jpg|thumb|right|Requirement Engineering - life cycle model]]Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system best as possible.<ref name="REBOOK" /><ref name="SWBOOK" /> The overall requirement life cycle in shown in the picture on the right.<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here. <ref name="SWBOOK" /> <br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px|Example on a process model for creating context for requirements]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right|Snow card template]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. <ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/> The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none|Example on chosen qualities ]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2901Requirements engineering2014-11-25T00:16:23Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context == <br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management. <ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <ref name="REBOOK" /><br />
<br />
= Creating requirements =<br />
[[File:LifeCycle.jpg|thumb|right]]Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system best as possible.<ref name="REBOOK" /><ref name="SWBOOK" /> The overall requirement life cycle in shown in the picture on the right.<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref> <ref name="elicitationWS">[''http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-fall2010/docs/Lecture-5/Tech-Req-Elicitation-Paper.pdf''] ''J. A. Gogen, C. Linde - Techniques for Requirements elicitation'' </ref><ref name="SREBOOK"> ''P. Loucopoulos, V. Karakostas - System Requirements Engineering'' </ref><br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here. <ref name="SWBOOK" /> <br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <ref name="SWBOOK" /> <ref name="REFPTBOOK" /> <ref name="contextPDF">[''http://www.wohlin.eu/rm_chapter05.pdf''] ''A. Aurum, C. Wohlin - Requirements engineering: Setting the context'' </ref><br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/><br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. <ref name="REBOOK" /><ref name="SWBOOK" /><ref name="SREBOOK"/> The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<ref name="REBOOK" /><ref name="SWBOOK" /><br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <ref name="REBOOK" /><ref name="REMBOOK"> ''C. Hood, S.Wiedermann, S. Fichtiner, U. Pautz - Requirements Management - ISBN: 978-3-540-47689-4'' </ref><br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
'''Links:'''<br />
*https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
*http://dl.acm.org/citation.cfm?id=545779<br />
<br />
'''Books:'''<br />
* E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition<br />
* S. Lauesen - Software Requirements<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2875Requirements engineering2014-11-24T23:41:10Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context == <br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management. <ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - Chapter 1 - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <ref name="REBOOK" /><br />
<br />
= Creating requirements =<br />
[[File:LifeCycle.jpg|thumb|right]]Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system best as possible.<ref name="REBOOK" /><ref name="SWBOOK" /> The overall requirement life cycle in shown in the picture on the right.<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together.<ref name="SWBOOK" /> <ref name="REFPTBOOK">'' K. Pohl - Requirements Engineering: Fundamentals, Principles, and Techniques - ISBN: 3642125778 9783642125775'' </ref><br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
http://dl.acm.org/citation.cfm?id=545779<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2864Requirements engineering2014-11-24T23:28:43Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context == <br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management. <ref name="REBOOK">''E.Hull, K. Jackson, J. Dick - Requirements Engineering 3rd edition - Chapter 1 - ISBN 978-1-84996-404-3'' </ref><ref name="SWBOOK">''S. Lauesen - Software Requirements - ISBN-13:9780201745702'' </ref><br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <ref name="REBOOK" /><br />
<br />
= Creating requirements =<br />
[[File:LifeCycle.jpg|thumb|right]]Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system best as possible.<ref name="REBOOK" /><ref name="SWBOOK" /> The overall requirement life cycle in shown in the picture on the right.<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
http://dl.acm.org/citation.cfm?id=545779<br />
<br />
= Bibliography =<br />
<references /><br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2801Requirements engineering2014-11-24T22:55:02Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
[[File:LifeCycle.jpg|thumb|right]]Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system best as possible. The overall requirement life cycle in shown in the picture on the right.<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
http://dl.acm.org/citation.cfm?id=545779<br />
<br />
= Bibliography =<br />
<br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2796Requirements engineering2014-11-24T22:53:07Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle: <br />
[[File:LifeCycle.jpg|thumb|right]]<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements=== <br />
[[File:SnowCard.jpg|thumb|right]]This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
http://dl.acm.org/citation.cfm?id=545779<br />
<br />
= Bibliography =<br />
<br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2788Requirements engineering2014-11-24T22:50:20Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle: <br />
[[File:LifeCycle.jpg|thumb|right]]<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements===<br />
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.[[File:SnowCard.jpg|thumb|right]]<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
= Related material =<br />
== Comparable stanards / recommendations ==<br />
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43564 - ISO/IEC 15288:2008<br />
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 - ISO/IEC 26702:2007<br />
<br />
== Additional related material ==<br />
https://www.youtube.com/watch?v=Ec0s0z5uXQ8&list=PLuge2MomyEekzECuCppJesmkv1tmUHCkB<br />
http://dl.acm.org/citation.cfm?id=545779<br />
<br />
= Bibliography =<br />
<br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2771Requirements engineering2014-11-24T22:41:58Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== Acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle: <br />
[[File:LifeCycle.jpg|thumb|right]]<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements===<br />
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.[[File:SnowCard.jpg|thumb|right]]<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
= Discussion =<br />
So why should one bother doing requirement engineering? Today systems exits everywhere where we go and where we are. Systems come in different shapes and size, for example many consumer devices and appliances are often computers systems, where other systems might be vehicles or engines. <br />
So systems has an influence and an affect on our everyday, and for everyday that goes by it gets even more influence in terms of newer and smarter technology. So depending on its purpose, the quality of systems can potentially have consequence ranging from minor inconveniences to a global disaster.<br />
That’s why today the most cost-effective way to achieve better quality is through requirement engineering. The fact is proven again and again over the last +30 years, but its still not really generally acknowledged for its importance. It should be emphasize the requirement engineering is not a solution by itself, but rather that a solution will contain requirements in some form. Therefore every persons involved in creating a system should have knowledge within the area of requirements engineering. <br />
<br />
== Strength and weknesses ==<br />
Requirements engineering is an effective and efficient way of creating high quality systems that addresses the client’s needs. It is in some cases also effective for making projects successful as wells as being the main reason for failure. <br />
Tough that the fact still remains the same, the benefit of requirement engineering to prevent faults and higher quality in systems, is one of its single largest contribution. Though it is time consuming, but it is cost-effective if done properly.<br />
<br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2009Requirements engineering2014-11-23T23:18:05Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle: <br />
[[File:LifeCycle.jpg|thumb|right]]<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements===<br />
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.[[File:SnowCard.jpg|thumb|right]]<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|none]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2007Requirements engineering2014-11-23T23:16:07Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle: <br />
[[File:LifeCycle.jpg|thumb|right]]<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none|700px]]<br />
<br />
===Functional requirements===<br />
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered.[[File:SnowCard.jpg|thumb|right]]<br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities. [[File:Qualities.jpg|thumb|left]]<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=2002Requirements engineering2014-11-23T23:00:40Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle: <br />
[[File:LifeCycle.jpg|thumb|right]]<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== Major concepts == <br />
===Requirements elicitation===<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
===Design and validation===<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
===Context===<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.[[File:ContextProcess.jpg|thumb|none]]<br />
<br />
<br />
===Functional requirements===<br />
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered. <br />
<br />
===Non-functional requirements===<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities.<br />
<br />
===Acceptance test===<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
===Requirement Management===<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=1988Requirements engineering2014-11-23T22:52:34Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle: <br />
[[File:LifeCycle.jpg|thumb|right]]<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== major concepts == <br />
'''Requirements elicitation'''<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
'''Design and validation'''<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
'''Context'''<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.<br />
<br />
'''Functional requirements'''<br />
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered. <br />
<br />
'''Non-functional requirements'''<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities.<br />
<br />
'''Acceptance test'''<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
'''Requirement Management'''<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=File:SnowCard.jpg&diff=1977File:SnowCard.jpg2014-11-23T22:45:42Z<p>Joh: picture comes from: http://ptgmedia.pearsoncmg.com/images/chap2_9780321815743/elementLinks/2_9_volere_snow_card_alt.jpg</p>
<hr />
<div>picture comes from: http://ptgmedia.pearsoncmg.com/images/chap2_9780321815743/elementLinks/2_9_volere_snow_card_alt.jpg</div>Johhttp://13.50.150.85/index.php?title=File:Qualities.jpg&diff=1976File:Qualities.jpg2014-11-23T22:44:53Z<p>Joh: picture comes from: https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en</p>
<hr />
<div>picture comes from: https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en</div>Johhttp://13.50.150.85/index.php?title=File:LifeCycle.jpg&diff=1974File:LifeCycle.jpg2014-11-23T22:43:41Z<p>Joh: </p>
<hr />
<div></div>Johhttp://13.50.150.85/index.php?title=File:ContextProcess.jpg&diff=1972File:ContextProcess.jpg2014-11-23T22:42:17Z<p>Joh: </p>
<hr />
<div></div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=1937Requirements engineering2014-11-23T21:41:40Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
= Background =<br />
This section describes the context in which requirements engineering is being used, as well as the history it has. This section also covers some examples on where requirement engineering plays a important role, in terms of projects gone bad and how it could be averted by defining proper requirements.<br />
<br />
== Application context ==<br />
Requirements is the basis for every project, it defines the stakeholders, users, customers, suppliers, etc. and their needs, which a potential new system can fulfill. In order to understand all involved parties, requirements are generally expressed in natural language and that is where the challenge lies. <br />
The challenge is to understand need or problem completely and unambiguously. Once an agreement between all involved parties is done, then the requirements will drive the project activity. The need of stakeholders may vary and introduce conflict, then the needs may not be clear defined from the start. It is about creating a mutual starting point and thereby creating stable requirements base. It is like setting off on journey without any idea of the destination. Though the intention of requirements is to be the map of that journey, so everybody would know where the journey is headed.<br />
In terms of management requirements forms the basis for:<br />
<br />
*Project planning<br />
*Risk management<br />
*Acceptance testing<br />
*Trade off<br />
*Change control<br />
<br />
There exists multiple examples on how project failures occurred because poorly defined requirements. A survey conducted by the Standish group in 1995 to 1996, shows the percentage of projects that stated various reasons for project failure. The result of that survey shows the problems fall in to three categories: Requirements (poorly defined or organized, weakly related to stakeholder, etc.), Management of resources (bad financial management, lack of support, no proper discipline and planning), Politics (which has influence on the to first problems).<br />
All factors can be addressed at a fairly low cost, by defining proper requirements and introduce proper requirements management.<br />
<br />
== acceptance and use ==<br />
The principles and practice of requirement engineering might be mostly used in software development, because of the currently dominant force of change of products. The trend is driven by three key factors, arbitrary complexity (The most complex systems tend to be software), Instant distribution (quick distribution around the world through of the internet), “off-the-shelf”-components (Systems tends to be constructed from bought in technology or ready made components, the could cause reduction in the product development cycle).<br />
Even though requirements engineering can be applied in other aspects than software. The same principles and practice also applies to other complete systems, for example consider developing a railway system that needs to go from city A to city B. If the distance between those cities are 300 km, than a high-level requirement may be the travel time should be less than 180 min.<br />
The point being that requirement engineering applies to systems. Where systems should be understood as a collection of components – machine, software or humans that will co-operate in an organized way to achieve some desired result – which is the requirements purpose to define that.<br />
There exist several standards on how to manage and use requirement engineering where one could be IEEE Std 1220-2005. But in the end it depends on what kind of system the requirements should define, were in some cases it will be likely the requirements will deviate from the standards. <br />
<br />
= Process of creating requirements =<br />
Requirement engineering can be done in different ways, the idea is to form the requirements accordingly to what a system is suppose to do. Even though there are certain phases a project most go through in order to achieve requirements that defines the overall system or application best as possible. The overall requirement life cycle:<br />
<br />
The proposed phases in this article are:<br />
<br />
*Ideation & Elicitation <br />
**Requirements elicitation<br />
*Elaboration<br />
**Design and validation<br />
**Context<br />
**Functional requirements<br />
**Non-functional requirements<br />
*Validation<br />
**Acceptance test<br />
*Management<br />
**Requirement Management <br />
<br />
== major concepts == <br />
'''Requirements elicitation'''<br />
Requirement elicitation is about organizing the knowledge one might have within a certain domain, and then structuring that knowledge by using some requirements elicitation techniques. Some of the techniques are self-explanatory, where other needs some further elaboration. The elicitation techniques are listed in the table below.<br />
--- TABLE ---<br />
{| class="wikitable"<br />
|+ Elicitation techniques<br />
|-<br />
| '''Objective Techniques'''<br />
* Data Analysis<br />
* Background Reading<br />
* System Archaeology<br />
* Laws & Regulations<br />
| '''Observational Techniques'''<br />
* Ethnographic field studies<br />
* Protocol Analysis<br />
* Apprenticing<br />
* Participant Observation<br />
|-<br />
| '''Conversational Techniques'''<br />
* Interviews<br />
* Surveys, Focus Groups<br />
* Group dynamics<br />
* Role Playing<br />
| '''Introspective Techniques'''<br />
* Storytelling<br />
* Personas<br />
* Brainstorming<br />
* Mind-Mapping<br />
|}<br />
<br />
The table shows 4 domains with each their elicitation techniques. In general they help create an objective and subjective understanding on what needs and goals the requirement should fulfill. <br />
The '''objective technique''' is to understanding as much as possible through documents, which could be e.g. from company reports, financial data, business processes, policy manuals, etc. Though the case is different for the system archaeology technique, which is about reengineering something that’s poorly documented. So the technique is about studying and analyzing a system to see if there should be any use full information.<br />
The '''observational technique''' is about being familiar with the surrounding environment for which the requirements need to fulfill. The technique is about being in the environment where the requirements will have influence.<br />
The ethnographic field study is about observing subjects in their usual environment and seeing them do the things they usually do. Domain experts are in the protocol analysis asked to do their regular tasks as usual, but speaking out loud what they are thinking. The apprenticing is as the word implies, apprenticing an experienced and representative person through the persons daily for work for a while. Participant observation is observing a subject over long time period and becoming a part of a group, without the person’s presence causing no threat to validity. <br />
The '''conversational technique''' derives requirements from conversations with subjects. It can be done through the mentioned techniques in the table, where the technique title implies how to derive requirements from the subject. <br />
The '''introspective technique''' should be called more like a creativity technique, because the requirements come from imagination. There are several ways of amplifying the imagination where some like everyday activities as well as physical actives can lead us in to daydreaming of aspects of system we haven’t thought of before. Even though the introspective technique provide ways of provoking our own mind to come up with these requirements.<br />
Storytelling is as the word implies telling a story about something relevant to the subject. Personas are fictional characters that prove useful when considering their goals, desire or limitations. Brainstorming and mind-mapping is a common way of structuring ideas, but this can also prove itself useful, both methods can be done in various ways, though one could be brainstorming trough a method called the 6-3-5 method. The 6-3-5 methods is where 6 people sit in a circle, the idea is then each person should write down 3 new ideas within 5 minutes, and then pass their paper to the left. All ideas should be read before writing down new ideas. After 6 rounds, the group should pin all ideas to a board and analyze them together. <br />
<br />
'''Design and validation'''<br />
This phase might be more minded for software development, but its intention can still be used in other situations in terms of visualizing possible system prototypes. The purpose of this process is to elicit and validate requirements through interaction design. It should be stressed that in this phase one should avoid committing too much to a specific design to ensure finding the best solution rather than proceeding with first random candidate. The key idea is to sketch, quick and dispensable design trough e.g. paper prototypes, mock-ups, etc. A sketch is defined, not by material or technique, but by function. In terms of validation, the design can be put in scenarios where role-play might be useful to validating the design, and securing that the design and requirements fulfills purpose of the system. More information about design and validation can be found here.<br />
<br />
'''Context'''<br />
In order to achieve the overall goal, the requirements most reflect the constraints the project has. This phase is about establishing the context for the requirements. That means identifying the people involved (stakeholders), and their motivations and goals. As well as covering the relevant aspects of the structure and culture of the target organization, that’s supposed to use and be affected by the requirements. Other possible relevant findings could be identifying systems or process that will have an influence or support function on the requirements. These findings are important in order to deliver requirements that will not be disruptive to any existing systems or processes. <br />
To better understand how to find the right context, here is a visualized example of steps to create the proper context for the requirements or project.<br />
<br />
'''Functional requirements'''<br />
This is among on of the most important phases in requirement engineering. It is the phases where the functional requirement for the overall goal is being identified, and documented. It is important that one should take their time meanwhile being thorough when creating the functional requirements. It is crucial that the written language is well formulated and contains a precise and consistent message, to leave out any doubt what the goal of the requirement is.<br />
The phases of the describing functional requirements can be complex and very hard to do. Though there exits various techniques and styles of specifying requirements. Each technique has an individual profile of pros and cons, which means it really depends on which kind of application the requirements are needed for. Among the well-known techniques, there are controlled languages, uses cases, snow cards, detailed attributed tables, etc.<br />
An example on the snow card technique is shown in the picture below. The picture is a snow card template that contains valuable attributes one should consider when creating a functional requirement. The idea to create a snow card for each requirement needed, until most functionality is covered or all business process is covered. <br />
<br />
'''Non-functional requirements'''<br />
In this phase we define the non-functional requirements, which is also known as a quality. Quality means a thing a system should have, thereby meaning something that wont affect the core functionality of the system. The qualities are by no means less important than functional requirements, because if the qualities are not being addressed an implementation is very likely to be completely unusable, irrespective of how good the rest may be. Because qualities are often crosscutting concerns, it is much more difficult to modify an existing system with new qualities, than modifying a functionality. <br />
It is important that the defined qualities are clear and precise, without providing too much detail. Because it’s tempting to specify a some in detail, but that might exclude better solutions at the given moment. <br />
There exits ISO standards that lists certain quality attributes, one could be the ISO/IEC 25010:2011 standard. The idea is then to go through the list and select qualities determined by system type, application areas, goals or the stakeholder’s opinion. To ensure the selected qualities make sense, linking them to system goal will only strengthen the argument why they should be applied to the system. The picture shows an example on list of selected qualities.<br />
<br />
'''Acceptance test'''<br />
As a quality assurance and making sure all involved parties are satisfied with the end product. An acceptance test is created to test if all requirements are realized in the system. In every engineering disciplines, there are various way of testing an system, for example in systems engineering it may involve black-box testing performed on a system, where in software development it may be user acceptance testing. A test case should be made for each functional requirement, where each test case should consists of three parts:<br />
<br />
* The trigger or pre-condition, and possibly some parameters<br />
* An operational procedure or action to be tested<br />
* The expected result, side effect, or post-condition<br />
<br />
'''Requirement Management'''<br />
This phase encompasses the overall process of requirement engineering, with a focus on management rather than engineering activates. The idea is to assess, prioritize, and track requirements, but it also extends to project management based on requirements engineering artifacts, and version control of requirements. Proper management of requirements will also lead to a better cost/effort control, and hopefully a successful project. <br />
There are various tools and methods in requirements management, to control requirements in more simple way. There exits a long list of different tools among them are: JIRA , Relatics, SpiraTest. <br />
<br />
<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=507Requirements engineering2014-11-15T20:23:06Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
The process of specifying a document with requirements is as follows:<br />
<br />
* Requirements Elicitation<br />
* Design and validation<br />
* Context<br />
* Specifying features (functional requirements)<br />
* Specifying quality attributes (non-functional requirements)<br />
* System structre modeling<br />
* Function and process modeling<br />
* Requirement Quality Assurance <br />
* Requirement Management<br />
<br />
[[Category:Systems Engineering]]<br />
[[Category:Project Management]]</div>Johhttp://13.50.150.85/index.php?title=Requirements_engineering&diff=317Requirements engineering2014-11-14T10:36:43Z<p>Joh: </p>
<hr />
<div>As part of systems engineering - requirements engineering is an important phase of the developing process of creating a new product, system or service. Often for a project to begin, a document specifying the formalities needs to be created in order to create common understanding among involved parties in a project.<br />
The requirements specify the needs and conditions from a client to help developers understand the goal of the product and the need it is fulfilling. <br />
The developers creates the requirements on the basis of the needs, to specific what the product is suppose to do and how it is going to do it. <br />
Requirements engineering is regarded as crucial in the development of product, because the outcome often creates the basis to get financial support. It’s basically the formal link between stakeholders and developers. <br />
The requirements can be created either by the stakeholder who wants something built as well as it can be the developer’s responsibility. Requirements engineering is considered a iterative process, so the requirements reflect a product best possible.<br />
<br />
The process of specifying a document with requirements is as follows:<br />
<br />
* Requirements Elicitation<br />
* Design and validation<br />
* Context<br />
* Specifying features (functional requirements)<br />
* Specifying quality attributes (non-functional requirements)<br />
* System structre modeling<br />
* Function and process modeling<br />
* Requirement Quality Assurance <br />
* Requirement Management</div>Joh