Abstract

AbstractSystem requirements engineering is relatively matured discipline with many trusted and dependable methods and techniques that fairly helps in identifying, analyzing, specifying, managing, verifying, and validating the system requirements. Yet the major challenge perceived in system engineering and development of software that is persisting over many years and pervasive across all domains is the requirements development, analysis, management, and validation. Still there are projects attributing to the defects in system requirements as the prime cause of its failure. Is a radical change to the current approach and techniques is essential or is it that we are not able to put the best practices designed into good use or both? Is there something else amiss that is not proportioned into these methods or tools and needs to be accounted into it? Several approaches attempt to increase the standardized portion by making it more objective and diminish the subjective substance. Towards this objective numerous tools and models were evolved over past several years aiming to standardize the requirements acquisition practice through various instruments like a questionnaire, design of use‐cases or models that consumes inputs from every stakeholder and use a standard template that brings in objectivity eliminating the ambiguity. These models are as intelligent as per the capabilities of the templates or the outlines created and matures per their exposure levels to the scenarios. They concentrates more on the methodology, patterns or blueprint to capture different characteristics and properties associated to the product in the requirements and the domain perspective is less deliberated. Domain viewpoint is of utmost importance to ensure the functioning of the product in the required environment and ambiance with required performance criteria that is suitable to the product. The “Domain Driven Design” is yet another approach to capture the requirements, develop and maintain it. A study of these three different approaches from the existing literature is done in this paper bringing out their prominent features, advantages and shortcomings. The proposed model delves deep into augment the domain facets of the products to ensure the definition of requirements are comprehensive and all‐inclusive to facilitate the flawless development and complete testing by reducing the ambiguity and enhancing the clarity. It also targets to produce all relevant artifacts like use cases, test scenarios, documentation etcetera. Collation and embedding of the precious and adept data from the experienced system engineers is one of the best features of the suggested model.

Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.