English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Plus monthly

Global: Zendy Tools annual

Global: Zendy Tools monthly

Global: Zendy Free Plan

Gathering business requirements can be a difficult process, especially when the final product requirements are dictated by a known client. Business requirement validation in cases where the requirements are gathered using text and graphics can be slow, error prone, and expensive. Misunderstandings and omitted requirements force additional revisions and increase a project's costs and delays. When issues related to the requirements are discovered later in the project, there are even greater costs and delays. Discovering or modifying requirements in the Design Phase can be three to six times more expensive, in the Coding Phase up to ten times more expensive, and in the Development Testing Phase between fifteen and forty times more expensive. In the Acceptance Phase, modifications can be thirty to seventy times more expensive, and in the Operation Phase it could be as high as forty to a thousand times more expensive (Dragon Point Inc., 2008). Architecture and design depends significantly on the Requirement Specifications. Misunderstandings or misinterpretations of the requirement can lead to wrong architectural and design decisions, as well as the propagation of failure into coding and latter project phases. One of the worst-case scenarios is when wrongly implemented requirements are discovered after deployment on the production platform. A research study reported that more than a quarter of completed projects contain only 25% to 49% of the originally specified features and functions (The Standish Group, 1995). The IBM Project Management presentation used the Meta Group study to illustrate that 70% of large IT projects failed or did not meet customer expectations (IBM, 2007). This paper proposes a new approach to the software development process to the improve requirements negotiation process and enable requirement validation during the requirement negotiation process. In the Generalized Requirement Approach (GRA), requirement validation is accomplished using automatically generated source and executable code without manual programming. The source code and executables are generated by the Generic Programming Units (GPU), the basis of the GRA Framework. The GRA Framework, which is the implementation of the GRA, provides guidelines for documenting and specifying requirements, methods, and libraries that are used to generate source code and executables. The questions that are part of the GRA Framework are guidelines for specifying a sufficient level of requirement detail to generate sources and executable code for requirement demonstration. Besides requirement documenting, tracking, and validating, this method addresses common requirement management syndromes, including a specification of an insufficient level of detail (Bulajic, Stojic, & Sambasivam, 2013a), the IKIWISI ("I'll know it when I see it") Syndrome, the Yes, But Syndrome ("That is not exactly what I mean"), and the Undiscovered Ruins Syndrome ("Now that I see it, I have another requirement to add"). This paper is organized in the following sections: 1. Introduction--this section 2. Background 3. Literature Survey 4. Traditional Software Development Method 5. Generalized Requirement Approach 6. Generalized Requirement Approach Framework 7. Retail Store Example Application 8. Summary of GRA Features and Comparison to other Approaches 9. Conclusion 10. References The section "Background" discusses the Software Development Methodology (SDM) and compares sequential and iterative software development processes. The section "Literature Survey" presents software development methods that have contributed to the software development process. This presentation is limited to the major methods that are currently used for software development. The section "Traditional Software Development Method (SDM)" is an overview of the current software development process structure that is common for the software development methods presented in the Section 3 "Literature Survey". …

The Generalized Requirement Approach for Requirement Validation with Automatically Generated Program Code