Requirements Engineering Dependability and Security Specification - HW6,7

HW6
4.5 Using the technique suggested [in the book], where natural language descriptions are presented in a standard format, write plausible user requirements for the following functions:
■An unattended petrol (gas) pump system that includes a credit card reader. The customer swipes the card through the reader then specifies the amount of fuel required. The fuel is delivered and the customer’s account debited.
The system should generate fuel and debit the customer's account when provided with a valid credit card.
■ The cash-dispensing function in a bank ATM.
The system should provide cash when a customer inputs valid identification for an eligible account.
■ The spelling-check and correcting function in a word processor.
The system should display spell-check information when the user provides a misspelled word in the processor.

4.6 Suggest how an engineer responsible for drawing up a system requirements specification might keep track of the relationships between functional and non-functional requirements.
There are many diagrams which can be helpful for keeping track of the relationships between requirements. This is especially true when attempting to construct requirements related to security. Using a modeling language such as Mal-Activity Diagrams or Secure Tropos can easily illustrate relationships between requirements, and even assist in constructing new requirements.

4.7 Using your knowledge of how an ATM is used, develop a set of use cases that could serve as a basis for understanding the requirements for an ATM system.
-Deposition of money
-Withdraw of money
-Entering PIN
-Checking balance
-Deposition of Check
-Entering Debit Card

HW7
The most common concerns issued by these articles focus around memory, development and planning. Beginning with The Magical Number Seven we have an article detailing the limits of human working memory and cognitive capacity. I wasn't entirely sure at first how this related to the other articles, so I'm making somewhat of a jump in connecting them.

Perhaps, with humans limited in their working memory, we can only visualize and focus on so much at a time which leads to the importance of planning and development strategies.

Development and planning are quite important, as I have emphasized in previous blogs. It's not possible with our cognitive capacity to keep everything in mind: testing requirements, security requirements, use cases, functional requirements, non functional requirements, etc. Therefore we reveal the importance of planning it all out, writing down requirements, looking ahead, creating test cases and working on creating an easier future development for software.

Taking a closer look at Planning for Failure in Cloud Applications there are many reasons emphasizing the importance of good development and organization. This is especially true in Cloud Applications which have some very high demands. One of these demands is availability, users require access to the promised services frequently, and uptime is very important for any service. When designing, for instance, a cloud platform as a service where uptime needs to be around 99.999% there should be fail safes designed for any uptime failures. Take Amazon EC2 for example: they have a huge user base and you can be absolutely sure that they'll have failures with their servers. They have designated backup servers that come into play when another server fails, they are running the same instances so there is a near flawless transition into the backup server until the original can be brought back online. This is an example of good planning that is necessary for the smooth operation of any system.

The article regarding Wireless Tire Pressure systems also illustrates an instance in which good development practices could have been executed with more finesse. Outlining the security requirements and use cases would have assisted in isolating any potential security problems/vulnerabilities that could appear in the future (such as the one discussed in the article). Additionally there could have been testing in place to make sure any included measures would be sufficient to prevent any privacy or security breaches into the system.

Lastly we have an article on test-driven development, another important practice. Instead of writing code and then testing it, a developer would first ensure that a test is in place for any of the code they intend to write. This helps ensure that the code is always testable, helping keep that code maintainable in the future.

Overall the articles just help further emphasize the importance of testable code and organized development practices. There are many tools in existence to help with the planning process, leading into the development process and ending with well-structured software. All that's left is for the developers to actually utilize these tools and follow their plans. That's not to say that plans never change, flexibility is important but if the code is testable it makes it all the easier to alter it.