Chapter 1: Software Requirements - Revision history

Daniel Robbins: /* Software Requirements Tools */

2015-08-20T20:33:22Z

‎Software Requirements Tools

Daniel Robbins at 20:26, 20 August 2015

2015-08-20T20:26:07Z

Daniel Robbins: /* Definition of a Software Requirement */

2015-08-20T20:23:50Z

‎Definition of a Software Requirement

Daniel Robbins: /* Software Requirements Tools */

2015-08-20T19:52:05Z

‎Software Requirements Tools

Daniel Robbins: /* Software Requirements Tools */

2015-08-20T19:50:10Z

‎Software Requirements Tools

Daniel Robbins: /* Software Requirements Tools */

2015-08-20T19:42:26Z

‎Software Requirements Tools

Daniel Robbins: /* Software Requirements Tools */

2015-08-20T19:42:02Z

‎Software Requirements Tools

Daniel Robbins: /* Practical Considerations */

2015-08-20T01:44:50Z

‎Practical Considerations

Daniel Robbins: /* Requirements Validation */

2015-08-20T01:43:35Z

‎Requirements Validation

Daniel Robbins: /* Requirements Specification */

2015-08-20T01:42:39Z

‎Requirements Specification

@@ Line 921: / Line 921: @@
 ad hoc and generally less satisfactory ways (e.g.,
 using spreadsheets).
 {{EndSection|title=References|body=

@@ Line 65: / Line 65: @@
 {{NoIndent|At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. The ways in which users, business processes, and devices function are typically complex. By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate.}}
-[[File:software-requirements.jpg|frame|Figure 1.1: Breakdown of Topics for the Software Requirements KA]]
+[[File:software-requirements.jpg|thumb|400px|frame|Figure 1.1: Breakdown of Topics for the Software Requirements KA]]
 An essential property of all software requirements is that they be verifiable as an individual

← Older revision		Revision as of 20:23, 20 August 2015
Line 64:		Line 64:

	{{NoIndent\|At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. The ways in which users, business processes, and devices function are typically complex. By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate.}}		{{NoIndent\|At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world. It may aim to automate part of a task for someone to support the business processes of an organization, to correct shortcomings of existing software, or to control a device—to name just a few of the many problems for which software solutions are possible. The ways in which users, business processes, and devices function are typically complex. By extension, therefore, the requirements on particular software are typically a complex combination from various people at different levels of an organization, and who are in one way or another involved or connected with this feature from the environment in which the software will operate.}}
		+
		+	[[File:software-requirements.jpg\|frame\|Figure 1.1: Breakdown of Topics for the Software Requirements KA]]

	An essential property of all software requirements is that they be verifiable as an individual		An essential property of all software requirements is that they be verifiable as an individual

@@ Line 925: / Line 925: @@
 |author=I. Sommerville
 |article=
-|publication=Software Engineering, 9th ed.
+|publication=Software Engineering
 |publisher=Addison-Wesley
 |issue=
@@ Line 936: / Line 937: @@
 |article=
 |publication=Software Requirements
-|edition=9th ed.
+|edition=2th ed.
 |publisher=Microsoft Press
 |issue=

@@ Line 952: / Line 952: @@
 |date=2012
 |part=
 |link=
 }}{{ReferenceList}}
 }}

@@ Line 953: / Line 953: @@
 |part=
 |link=
-}}{{reference
+}}{{ReferenceList}}
-|number=3
-|author=INCOSE
-|article=
-|publication=Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
-|edition=version 3.2.2
-|publisher=International Council on Systems Engineering
-|issue=
-|date=2012
-|part=
-|link=
-}}
 {{ReferenceList}}
 }}

← Older revision		Revision as of 19:42, 20 August 2015
Line 919:		Line 919:
	ad hoc and generally less satisfactory ways (e.g.,		ad hoc and generally less satisfactory ways (e.g.,
	using spreadsheets).		using spreadsheets).
		+
		+	{{EndSection\|title=References\|body=
		+	{{reference
		+	\|number=1
		+	\|author=I. Sommerville
		+	\|article=
		+	\|publication=Software Engineering, 9th ed.
		+	\|publisher=Addison-Wesley
		+	\|issue=
		+	\|date=2011
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=2
		+	\|author=K.E. Wiegers
		+	\|article=
		+	\|publication=Software Requirements
		+	\|edition=9th ed.
		+	\|publisher=Microsoft Press
		+	\|issue=
		+	\|date=2003
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=3
		+	\|author=INCOSE
		+	\|article=
		+	\|publication=Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
		+	\|edition=version 3.2.2
		+	\|publisher=International Council on Systems Engineering
		+	\|issue=
		+	\|date=2012
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=3
		+	\|author=INCOSE
		+	\|article=
		+	\|publication=Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
		+	\|edition=version 3.2.2
		+	\|publisher=International Council on Systems Engineering
		+	\|issue=
		+	\|date=2012
		+	\|part=
		+	\|link=
		+	}}
		+	{{ReferenceList}}
		+	}}

← Older revision		Revision as of 01:44, 20 August 2015
Line 718:		Line 718:

	== Practical Considerations ==		== Practical Considerations ==
		+
		+	{{RightSection\|{{referenceLink\|number=1\|parts=c4s1, c4s4, c4s6, c4s7}} {{referenceLink\|number=2\|parts=c3, c12, c14, c16, c18-21}}}}

	The first level of topic decomposition presented		The first level of topic decomposition presented

@@ Line 590: / Line 590: @@
 == Requirements Validation ==
+{{RightSection|{{referenceLink|number=1|parts=c4s6}} {{referenceLink|number=2|parts=c13, c15}}}}
 The requirements documents may be subject to validation
 and verification procedures. The requirements

← Older revision		Revision as of 01:42, 20 August 2015
Line 479:		Line 479:

	== Requirements Specification ==		== Requirements Specification ==
		+	{{RightSection\|{{referenceLink\|number=1\|parts=c4s2, c4s3, c12s2-5}} {{referenceLink\|number=2\|parts=c10}}}}

	For most engineering professions, the term “specification”		For most engineering professions, the term “specification”