User:Usydwork/sandbox

From Wikipedia, the free encyclopedia

Acceptance Criteria (Software Engineering)[edit]

Acceptance Criteria
A simple template for Acceptance Criteria
An example of traditional approach for Acceptance Criteria
Usage
Methods
CompoenentsEntry Criteria, Exit Criteria,Testing activity, Input(Parameter), ouput
StakholdersCustomers, end-users and testers


Acceptance criteria is a form of documentation in Software development, defining a specific set of goals and requirements.[1] The purpose of Acceptance Criteria is to satisfy the user or customer requirement through clearly listing the expectations for a shippable software product.[2] Development of a software project is primarily based on the reasonable expectation from the client.[3] The result of the project requires to be "accepted" before delivery as a shippable product.[4] Therefore, setting specific guidelines can eliminate unnecessary assumption between the customer and the developers.[5]

Acceptance testing can only be implemented if the Acceptance Criteria exists.[6] Acceptance tests use acceptance criteria as a testing guideline to carry out if the shippable project can be accepted or not.[4] The difference with Acceptance Testing is in the nature of enactment of the “test”. Acceptance Criteria focuses on how the requirements are fulfilled from various perspectives from different stakeholders instead of application to the implementation.[7][8]



Importance of Acceptance Criteria[edit]

Acceptance Criteria demonstrates the expectation of the client, which aims to achieve the highest quality system.[2] System function(input and output) and functional (performance, interface and environment) can be summarised in Acceptance Criteria.[9] Discovering a system consideration defect at the beginning of the design phrase produces the most economically efficient way to reduce the cost of fixing the defect.[10]

The major cause of system and software failure are often due to inadequate requirement and implementation of Acceptance Criteria.[11] A mission-critical failure can cause serious harm, with operational failure as a consequence. Moreover, potential litigation and losing public confidence can be a problematic extension, resulting in significant financial loss for organisations.[12]

Failures of Software development[edit]

Bank, government services, aerospace (such as the system in airplane or rocket), technology companies etc. can all be affected by system failure.[13] History presents many past events of failures in large scale software projects because of the lack of care or unthoughtful Acceptance Criteria that leads to disastrous consequence such as significant financial loss and deaths. Therefore, Acceptance Criteria acts as a critical written document that ensures the systems or software can operate with the expected results.  [14]

Components of Acceptance Criteria[edit]

Acceptance Criteria can have different characteristics which can be functional, ergonomic, behaviour, sensory and temporal.[15]

  • An Objective: The proposed aim of the Criteria.[15]
  • Scope of Acceptance Criteria: Specific processes of the Criteria to achieve the desired outcome[16]
  • Criteria for user, operations and product:
    • Entry Criteria: Defines how a test can commence[17]
    • Exit Criteria: Defines when the test can finish and deliver output[17]
    • The activity: The defined process obtain input and produce the output[15]
    • Input and output: Different boundary can be set for the inputs. The output is treated as a result.[15]

Consideration in Acceptance Criteria[edit]

Acceptance Criteria in Software development takes part of all phrases of consideration

The following has a list of questions to ask before creating Acceptance Criteria.

Are the results of Acceptance Criteria measurable? The results must be measurable to ensure that the target can be fulfilled.[18]  

Who or which department is responsible for testing the code? Proper guidance and competencies should be provided along with the Acceptance Criteria to standardise the testing process as testers will be [19]

What are the boundaries for inputs and outputs? A well-defined relationship between inputs and output can prevent errors such as overflow and calculation errors.[18]

How often or when does the testing occur? The outcome of implementing the acceptance Criteria can be affected by the consistency of measurement.[18]

An example of the Campus Management System[edit]

Educational institutions are now facing a competitive challenge which wishes to use information technology to contrive a system for better user experience and maintenance.[20] Acceptance criteria needs to take an essential role as the system has tailored with the user’s needs and suit the user-friendliness as a modern expectation.[21] Some of the essential techniques are to identify the demographics, understand about users needs of the technology, investigate how satisfied are the end-users with any new system, and to analyse the current usage of CMS.[22]

Verification and Validation[edit]

Verification and Validation takes an important role in V model method for fulfilling the Acceptance Criteria.[23]

Verification and validation are two different processes to determine if the Acceptance Criteria have been fulfilled. They both have the objective of ensuring the well-defined Criteria.

Verification: Are were building the product right? Validation: Are we building the right product?

The above definition provides a distinct difference in how Verification and validation apply to Acceptance Criteria. Verification sets the guidelines if the project has used good practice during the system development. Validation focuses on the outcome if the formal requirements are adequately satisfied. [24][25]

Ethics[edit]

Although the operational and functional measure of a system or software is indispensable for Acceptance Criteria, ethics is one of the notable considerations as the accessibility to the web platform impact the day-to-day life.[26] Cultural, ethnic, religious, social, sexual factors are all part of ethics.[27] Large scale platform such as online games and social media can cause an unpredictable adverse effect, causing cause both benefits and harm due to overuse or misuse.[28] The “dual-use” of web innovation is a tough dilemma for both users and the social responsibility of the developers Therefore, responsibility and accountability of balancing the interests of all parties in Acceptance Criteria is part of the design consideration for Acceptance Criteria. [29]


Acceptance Criteria for Agile approach[edit]

Instead of the traditional method such as waterfall model for creating Acceptance criteria at the beginning, Acceptance Criteria is employed quickly and in short iterations from agile practices, enabling the action of building the small and shippable product in a short time frame.[30] The requirement from Acceptance Criteria is the result of effective communication from agile meeting, retrospectives and workshop. As the agile works in an iterative and quick manner, the Acceptance Criteria can flexibly capture requirement from the client for every sprint. The small and nimble Acceptance Criteria enables the project development to be more responsive to the changes in client requirement. [31]

Tools[edit]

A collection of user story in a map

Agile practice typically utilises use cases and user stories as part of the highly flexible Acceptance Criteria, which can help to capture requirements from different stakeholders perspectives.[32] Clients or developers can then determine the acceptability of the shippable product on an acceptance or rejection basis.[33]





Reference[edit]

  1. ^ Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. p. 21. ISBN 9781118603093. OCLC 827207542.
  2. ^ a b Gu, Tingyang; Li, Jiao (2011). "A discussion on the software programming technology". The Proceedings of 2011 9th International Conference on Reliability, Maintainability and Safety. IEEE: 658. doi:10.1109/icrms.2011.5979371. ISBN 9781612846675.
  3. ^ Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. pp. 63, 103. ISBN 9781118603093. OCLC 827207542.
  4. ^ a b Gu, Ting yang; Li, Jiao (2011). "A discussion on the software programming technology". The Proceedings of 2011 9th International Conference on Reliability, Maintainability and Safety. IEEE: 660. doi:10.1109/icrms.2011.5979371. ISBN 9781612846675.
  5. ^ Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. p. 172. ISBN 9781118603093. OCLC 827207542.
  6. ^ Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. p. 77. ISBN 9781139010290. OCLC 707078807.
  7. ^ Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. p. 78. ISBN 9781139010290. OCLC 707078807.
  8. ^ Rashid, Awais; Weckert, John; Lucas, Richard (2009). "Software Engineering Ethics in a Digital World". Computer. 42 (6): 39. doi:10.1109/mc.2009.200. ISSN 0018-9162.
  9. ^ Gu, Tingyang; Li, Jiao (2011). "A discussion on the software programming technology". The Proceedings of 2011 9th International Conference on Reliability, Maintainability and Safety. IEEE: 659. doi:10.1109/icrms.2011.5979371. ISBN 9781612846675.
  10. ^ Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. p. 12. ISBN 9781118603093. OCLC 827207542.
  11. ^ Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. ISBN 9781118603093. OCLC 827207542.
  12. ^ Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. p. 13. ISBN 9781139010290. OCLC 707078807.
  13. ^ Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. ISBN 9781118603093. OCLC 827207542.
  14. ^ Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. ISBN 9781118603093. OCLC 827207542.
  15. ^ a b c d Homes, Bernard (2013). Fundamentals of Software Testing. Wiley. p. 10. ISBN 9781118603093. OCLC 827207542.
  16. ^ Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. p. 11. ISBN 9781139010290. OCLC 707078807.
  17. ^ a b Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. p. 149. ISBN 9781139010290. OCLC 707078807.
  18. ^ a b c Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. pp. 99–100. ISBN 9781139010290. OCLC 707078807.
  19. ^ Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. p. 38. ISBN 9781139010290. OCLC 707078807.
  20. ^ Shaffiei, Zatul Amilah; Mokhsin, Mudiana; Hamidi, Saidatul Rahah; Yusof, Noreha Mohamed (2011). "A study of user's acceptance and perception towards Campus Management System (CMS) using Technology Acceptance Model (TAM)". 2011 3rd International Congress on Engineering Education (ICEED). IEEE: 128. doi:10.1109/iceed.2011.6235374. ISBN 9781457712593.
  21. ^ Shaffiei, Zatul Amilah; Mokhsin, Mudiana; Hamidi, Saidatul Rahah; Yusof, Noreha Mohamed (2011). "A study of user's acceptance and perception towards Campus Management System (CMS) using Technology Acceptance Model (TAM)". 2011 3rd International Congress on Engineering Education (ICEED). IEEE: 129. doi:10.1109/iceed.2011.6235374. ISBN 9781457712593.
  22. ^ Shaffiei, Zatul Amilah; Mokhsin, Mudiana; Hamidi, Saidatul Rahah; Yusof, Noreha Mohamed (2011). "A study of user's acceptance and perception towards Campus Management System (CMS) using Technology Acceptance Model (TAM)". 2011 3rd International Congress on Engineering Education (ICEED). IEEE: 130. doi:10.1109/iceed.2011.6235374. ISBN 9781457712593.
  23. ^ Dick, Jeremy; Hull, Elizabeth; Jackson, Ken (2018). REQUIREMENTS ENGINEERING. SPRINGER INTERNATIONAL PU. pp. 91–92. ISBN 3319869973. OCLC 1085149709.
  24. ^ Watkins, John (2011). Testing IT : an off-the-shelf software testing process. Cambridge University Press. p. 12. ISBN 9781139010290. OCLC 707078807.
  25. ^ Deuff, Dominique; Cosquer, Mathilde (2013-05-06), "Description of the User-Centered Agile Method", User-Centered Agile Method, John Wiley & Sons, Inc., pp. 82–83, ISBN 9781118574829, retrieved 2019-05-19
  26. ^ Rashid, Awais; Weckert, John; Lucas, Richard (2009). "Software Engineering Ethics in a Digital World". Computer. 42 (6): 37. doi:10.1109/mc.2009.200. ISSN 0018-9162.
  27. ^ Rashid, Awais; Weckert, John; Lucas, Richard (2009). "Software Engineering Ethics in a Digital World". Computer. 42 (6): 36. doi:10.1109/mc.2009.200. ISSN 0018-9162.
  28. ^ Rashid, Awais; Weckert, John; Lucas, Richard (2009). "Software Engineering Ethics in a Digital World". Computer. 42 (6): 35. doi:10.1109/mc.2009.200. ISSN 0018-9162.
  29. ^ Rashid, Awais; Weckert, John; Lucas, Richard (2009). "Software Engineering Ethics in a Digital World". Computer. 42 (6): 38–39. doi:10.1109/mc.2009.200. ISSN 0018-9162.
  30. ^ Deuff, Dominique; Cosquer, Mathilde (2013-05-06), "Description of the User-Centered Agile Method", User-Centered Agile Method, John Wiley & Sons, Inc., p. 81, ISBN 9781118574829, retrieved 2019-05-19
  31. ^ Deuff, Dominique; Cosquer, Mathilde (2013-05-06), "Description of the User-Centered Agile Method", User-Centered Agile Method, John Wiley & Sons, Inc., pp. 9–10, ISBN 9781118574829, retrieved 2019-05-19
  32. ^ Deuff, Dominique; Cosquer, Mathilde (2013-05-06), "Description of the User-Centered Agile Method", User-Centered Agile Method, John Wiley & Sons, Inc., p. 11, ISBN 9781118574829, retrieved 2019-05-19
  33. ^ Deuff, Dominique; Cosquer, Mathilde (2013-05-06), "Description of the User-Centered Agile Method", User-Centered Agile Method, John Wiley & Sons, Inc., pp. 98–100, ISBN 9781118574829, retrieved 2019-05-19



Category:Methodology Category:Software engineering

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Usydwork/sandbox&oldid=898536291"