Software Engineering Requirements Gathering Key Points

Architecture, Infrastructure, Design elicitation.

Please note: Tim has two of the schools software engineering books. Ask and you shall receive thy book(s)

1. Requirements for a software system set out what the system should do and define constraints on its operation and implementation.

2. Functional requirements are statements of the services that the system must provide or are descriptions of how some computations must be carried out.

3. Non-functional requirements often constrain the system being developed and the development process being used. These might be product requirements, organizational requirements or external requirements. They often relate to the emergent properties of the system and therefore apply to the system as a whole.

4. The requirements engineering process includes requirements elicitation (Friday @ 1pm) requirements specification, requirements validation, and requirements management.

   • We'll focus on post the elicitation on the the item 4.

5. Requirements elicitation is an iterative process that can be represented as a spiral of actives - requirements discovery, requirements classification and organization, requirements negotiation and requirements documentation.

   • Requirements elicitation and analysis: This is the process of deriving the system requirements through observation of existing systems, discussion with potential users and procurers, task analysis, and so on. This may involve development of one or more system models and prototypes. These help you understand the system to be specified.

6. Requirements specification is the process of formally documented the user and system requirements and creating a software requirements document.

   • Requirements specification: Requirements specification is the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided.

7. The software requirements document is an agreed statement of the system requirements. It should be organized so that both system customers and software developers can use it.

   • Number 7 is also very important: We must get an agreed and signed requirements document.

8. Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism and verifiability.

   • Requirements validation: This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.

   • Number 8 is important too: There's a lot that goes into this project that will require research and such. We're lucky to have Kees as he's done this type of work before and is a software engineer, so I'm sure he'll help us here.

9. Business, organizational and technical changes inevitably lead to changes to the requirements for a software system. Requirements management is the process of mangling and controlling these changes.

   • Number 9 falls on me, but I'll count on yall to bring things up so we can mitigate and maneuver around them, relax constraints, or seek out more information.

   • Hardware → Can/will Kees get us access to a test environment or do we need to drum up our own? Is this project in CLANG or LLVM? This is an important question because CLANG -hugely- limits the scope (which is a really good thing!) because it only handles a handful of languages. Networking: can Kees get us into contact with LLVM people in addition to himself via whatever means necessary in case we have lots of questions (I know I will) that might be easier to source from a specialist(s) who wants to help.

   • C++ versioning. As mentioned, is this going to be C++14 or C++17? Scope/priority: what does Kees view as the “core” product he wants to see versus what are things that would be awesome to have but aren’t inherently “required” so we can pare this down and see what the real heart of it is. Generally a prioritizing of the goals outlined in the slides, basically.