Key term
CCEA A-Level Software Systems Development CL4
Software and the Development Environment
Topic overviewSystems software and application softwareThe operating system and file managementSource code filesBinary, object and executable filesCompilers, interpreters and the build processXML files and structured dataUtility software and managing files on diskThe integrated development environmentObject oriented development platformsOpen source software and licensing
Defining Data: Types, Variables and Classes
Topic overviewPrimitive types and their storageReference types, objects and nullDeclaring variables, scope and lifetimeType casting and conversionArithmetic operators and expressionsRelational and logical operatorsOperator precedence and evaluation orderObjects as occurrences of a classAbstract, base and inherited classesAttributes and the properties of a classStatic variables in a classInterfaces and class reusability
Program Control Structures
Topic overviewSequence and the order of executionMethods and passing control between themSelection with IF and IF ELSENested IF and multi-way selectionThe switch statementCount-controlled repetition with FORConditional repetition with WHILE and DO WHILENested loops and tracing iterationsBreaking out of loops and avoiding infinite loopsChoosing and evaluating control structures
Objects, Classes and Data Structures
Topic overviewConstructors and creating objectsMethods, parameters and return valuesEncapsulation and access modifiersGetters, setters and validating an object's stateInheritance and the base classOverriding methods and run-time polymorphismOverloading methodsChoosing and organising data structuresStrings and string handlingStatic arrays of simple typesArrays of objects
Exception Handling and Managing Input and Output
Topic overviewWhy errors have to be trappedTypes of error and how an exception is raisedThe try and catch blockCatching more than one kind of exceptionThe finally block and releasing resourcesThrowing exceptions and writing an exception classChecked and unchecked exceptionsReading and validating input from the command lineControlling screen outputText filesBinary filesObject files and serialisation
Testing an Object Oriented Application
Topic overviewWhy an object oriented application must be testedChoosing test data: normal, boundary and erroneousWriting a test plan for a classTesting a class method by methodTesting constructors and object stateTesting inheritance and overridden methodsTesting error handling pathsDry runs and trace tablesTest harnesses, drivers and stubsRecording and interpreting test resultsEvaluating a test plan and re-testing
Graphical User Interface Objects and Events
Topic overviewGraphical user interfaces and console programsForms and their common propertiesLabels, text boxes and text areasButtons, check boxes and radio buttonsLists, combo boxes and other selection controlsProperties, methods and events of a GUI objectContainers, panels and laying out a formThe event loop and the event queueEvent handlers and registering a listenerThe event object and reading it inside a handlerButton, mouse and keyboard triggers
Multiple Forms and Linking to Files
Topic overviewWhy an application needs more than one formCreating, showing, hiding and closing a formModal and modeless formsPassing data between formsMenus, menu items and shortcutsToolbars and navigation buttonsDesigning navigation for a multi form applicationReading and writing text filesBinary files and streamsObject serialisation and object filesChoosing between text, binary and object files
Designing, Testing and Evaluating an Event Driven Application
Topic overviewStoryboards and what they showBuilding a storyboard from user requirementsPrototyping and refining a designError trapping in an event driven applicationUsing try and catch inside an event handlerValidating what a user types into a controlDesigning a test strategy for an event driven applicationTest plans and choosing test dataTesting the paths a user takes through an interfaceDocumenting and interpreting test resultsEvaluating an application against its requirementsEvaluating features, functionality and usability
Reasons for Systems Development and Systems Methodologies
Topic overviewWhy organisations initiate systems developmentAnalysis and design principles for business solutionsRoles in development and the place of the userThe purpose of a methodology and how methodologies evolvedThe waterfall modelIterative, incremental and spiral developmentRapid application developmentThe dynamic systems development methodScrumExtreme programmingPrototyping in the development processUML modelling and simple diagrams
Managing Projects
Topic overviewThe purpose of project managementProject management concepts and the project life cycleRoles and responsibilities in project managementResources needed to develop a projectEstimating effort, duration and costGantt charts and the scheduleMilestones and checkpointsNetwork diagrams and PERTFinding the critical pathFloat and how it is usedMonitoring and controlling progressManaging risk and change
Testing Strategies
Topic overviewWhy testing matters throughout the development cycleTesting at the design stageProgram and unit testingIntegration testingSystem testingWhite box testingBlack box testingNormal, boundary and erroneous test dataUser acceptance, alpha and beta testingThe personnel involved in testingWhat a test plan containsBuilding a test plan for a scenario
Database Concepts and Entity Relationship Modelling
Topic overviewWhat a database is and why one is usedDatabase terminology: fields, records and keysThe relational modelThe hierarchical modelThe network modelEntities and attributes in an ER modelRelationships and their degreeBuilding an ER model for a problemFrom ER model to a working designComparing the three database models
Normalisation and Structured Query Language
Topic overviewWhy data is normalisedUn-normalised data and repeating groupsFirst normal formSecond normal formThird normal formWorking a full normalisation throughThe advantages and limits of normalisationThe principles of SQLSQL commands for defining and changing dataSQL statements for retrieving dataJoining tables and grouping results
Project Management and the Systems Approach in Practice
Topic overviewBreaking a development into tasks and deliverablesEstimating durations, effort and dependenciesDocumenting the plan as a Gantt chartWorking out the critical path and floatMilestones, reviews and user sign-off pointsPlanning people, resources and skillsBuilding a plan capable of reflecting changeRecording progress against the planUpdating the plan to reflect slippageRecording change requests and versions of the planEvaluating different approaches to a business problemSelecting and justifying a specific approach
Defining Requirements and Documenting the Design
Topic overviewEliciting requirements from the userWriting functional requirementsWriting non-functional requirementsSpecifying the software and hardware the solution needsProducing and agreeing the user requirements specificationDesigning the data model and the tablesDesigning the inputs, the screens and the navigationDesigning the outputs and the reportsDocumenting the processes and the logic of the solutionTesting the design against the desired user outcomesPresenting the design and the solution using appropriate media
Building a Desktop Solution with a Database
Topic overviewApplying relational techniques to a real solutionChoosing the database and the development toolConnecting the application to the databaseData adaptorsData setsData commands and parameterised queriesBinding the database to the interfaceMultiple forms and navigationSaving changes and protecting the dataTesting and documenting the built solution
Testing and Evaluating the Solution
Topic overviewPlanning the testing of the finished solutionChoosing test data: normal, boundary and erroneousTesting validation and error handlingTesting the database and its queriesTesting the user interface and the navigationTesting the whole solution and testing with the userDocumenting test outcomes as evidenceDiagnosing failures and retestingEvaluating the test proceduresEvaluating the solution against the user requirementsEvaluating delivery against the project planEvaluating your own performance on the development
Defining Requirements and Documenting the Design
- 11 subtopics
- 33 things to know
- A2 Unit 2
What Defining Requirements and Documenting the Design covers
Defining Requirements and Documenting the Design is examined in Unit A2 2, Implementing Solutions — an internally assessed portfolio. It covers Eliciting requirements from the user, writing functional requirements, writing non-functional requirements, specifying the software and hardware the solution needs, producing and agreeing the user requirements specification, designing the data model and the tables, designing the inputs, the screens and the navigation, designing the outputs and the reports, documenting the processes and the logic of the solution, testing the design against the desired user outcomes and presenting the design and the solution using appropriate media.
Where it is assessed
A2 Unit 2
Implementing Solutions — an internally assessed portfolio.
Check the CCEA specification ↗The 11 subtopics
Each one has its own page.
- Eliciting requirements from the userPurpose of requirements elicitation, four techniques for gathering requirements from a business user and one weakness of a questionnaire as a requirements technique.Open →
- Writing functional requirementsFunctional requirement, atomic requirement and four categories MoSCoW prioritisation uses.Open →
- Writing non-functional requirementsNon-functional requirement, what a usability requirement states and what a reliability requirement states.Open →
- Specifying the software and hardware the solution needsMinimum and recommended hardware and software licence requirement.Open →
- Producing and agreeing the user requirements specificationUser requirements specification and traceability reference.Open →
- Designing the data model and the tablesDeriving the tables from the client's own documents, normalising to third normal form, recording every column with its type, size, validation and key role, and choosing the integrity rule for each relationship.Open →
- Designing the inputs, the screens and the navigationDeciding what is captured on which form and in what order, choosing controls that make an invalid entry impossible, specifying the validation on each field, and recording the layout as an annotated design.Open →
- Designing the outputs and the reportsWhat is meant by the outputs of a solution, grouping in a report and exception report.Open →
- Documenting the processes and the logic of the solutionDescribing what each process does and produces, writing algorithms for anything involving calculation, decision or repetition, and checking them by hand before any code is written.Open →
- Testing the design against the desired user outcomesDesign walkthrough and what a traceability matrix contains.Open →
- Presenting the design and the solution using appropriate mediaPresenting a solution using appropriate media and recorded after the design has been presented to the user.Open →
What you need to know
Answer each one before you reveal it.
Your recallNot started
Key term
Why is a functional requirement numbered, who does it belong to, and what makes one atomic?
Key term
Define a non-functional requirement.
Key term
Why does a user requirements specification state the software the solution needs?
Key term
Define a user requirements specification.
Key term
Define a data model in a solution design.
Key term
What does designing the inputs of a solution involve?
Key term
Explain what is meant by the outputs of a solution.
Process
How is a process documented in the design?
Key term
What does it mean to test a design?
Key term
Name four media suitable for presenting a design to a business user.
Key term
State the purpose of requirements elicitation.
Key term
Define a functional requirement.
Key term
Name five categories of non-functional requirement.
Key term
Name three pieces of software a database-driven desktop solution depends on.
Key term
Which sections would you expect a user requirements specification to contain?
Key term
How are the entities for the data model found from the requirements?
Key term
Why is the input design based on the order the user works in?
Key term
Which questions must be answered before a report is designed?
Process
Why is pseudocode used to record the logic of a process?
Key term
Why is a design tested before coding rather than afterwards?
Key term
Why is a live demonstration the strongest medium for presenting a finished solution?
Key term
Name four techniques for gathering requirements from a business user.
Key term
Give three examples of functional requirements for a stock control solution.
Key term
Turn "the system must be fast" into a measurable requirement.
Key term
Distinguish between minimum and recommended hardware.
Key term
Why is the requirements document agreed and signed by the user before design begins?
Key term
What does an ER diagram contribute to a design document?
Key term
Which control suits a field with a small fixed set of allowed values?
Key term
What does a report design specify?
Key term
Give the pseudocode logic for adding a delivery to the quantity held for a product.
Key term
Describe a design walkthrough.
Key term
When is a recorded demonstration better than a live one?
Take Defining Requirements and Documenting the Design further
The same content, four other ways.
Commonly confused
Pairs that lose marks when they are blurred together.
Report grouping vs Report sorting
Report grouping: collecting records sharing a value under a heading with a subtotal. Report sorting: fixing only the sequence in which records appear.
Prototype vs Screen layout drawing
Prototype: a partial working version that can be clicked through and reacted to. Screen layout drawing: a still picture that can only be looked at and annotated.
Questions from this topic
Each one with the model answer underneath.
- 1
State the purpose of requirements elicitation.
Model answer
Requirements elicitation finds out what the user actually needs the solution to do, before any design work begins.
- 2
Name four techniques for gathering requirements from a business user.
Model answer
Interviews, questionnaires, observation of the current working practice and inspection of existing documents are all used.
- 3
When is an interview the best technique for gathering requirements?
Model answer
An interview suits a small number of key users, because an answer can be followed up and a misunderstanding cleared at once.
- 4
Why is a questionnaire used when many staff are affected?
Model answer
A questionnaire reaches a large number of people quickly and cheaply, and the answers can be counted.
- 5
State one weakness of a questionnaire as a requirements technique.
Model answer
A questionnaire cannot ask a follow-up question, so an unexpected answer cannot be explored.
- 6
What does observing the user at work reveal that an interview does not?
Model answer
Observation reveals what people actually do, including the shortcuts and workarounds they forget to mention.
What is inside Levo
Six ways to work the same material.
Defining Requirements and Documenting the Design revision questions
- What does Defining Requirements and Documenting the Design cover in CCEA A-Level Software Systems Development?
- 11 subtopics: eliciting requirements from the user, writing functional requirements, writing non-functional requirements, specifying the software and hardware the solution needs, producing and agreeing the user requirements specification, designing the data model and the tables, designing the inputs, the screens and the navigation, designing the outputs and the reports, documenting the processes and the logic of the solution, testing the design against the desired user outcomes and presenting the design and the solution using appropriate media. Each one has its own page with questions and model answers.
- How is Defining Requirements and Documenting the Design organised?
- By the CCEA CL4 specification, subtopic by subtopic, so it matches the order you are taught it in.
Every question in Defining Requirements and Documenting the Design, on a schedule.
Attempt a question from memory, write the correct version, then attempt it again. Levo records the jump between your first attempt and your last, and brings each question back on the day you are due to forget it.
Or £46 a year, about £3.83 a month. Cancel anytime.