In a way, every software security assessment is an exercise in software development. The first step in the software security assessment project is requirements analysis. Requirements analysis is concerned with what the system (whether it be a “traditional” application or a rich Web 2.0 application for social networking) needs to do. This involves examining the requirements of the business itself, the users of the application against the backdrop of cost and engineering constraints such as throughput and response time when the application is deployed on a cloud computing platform.

Business Requirements

• Business Requirements analysis – Describe the business and its it’s customers, suppliers and users, problems, issues and expectations. This is essential when developing a new application, but also crucial when you’’re making significant changes to an application. “Why” do you want to develop the software and “how much” is it going to cost? Is there a ROI (return on investment). Can your team develop and implement the product?
• P.I.E – – Problems Issues and Expectations – Describe current problems and put the issues and expectations that users have in the current environment into separate categories. An expectation may be crucial to success of the project or it may be a “user satisfaction” feature that can be postponed to Revision 9.5
• Causes and Consequences – Discuss causes of current system problems and their consequences. You will discover that a problem’s result is often a problem in it’s own right. You need to drill down to the root cause of the problem peeling away the symptoms.
• Target system tasks – Discuss and observe users as they work with the software application. Remember that the important things are (a) how easy it is to install/start using a product (b) how fast it works and c) how intuitive is the UI. This is particularly relevant to Web-based applications, where the user experience will make or break the application.
• System Design Alternatives Analysis – Very few systems are new. In alternatives analysis you will consider the strengths and weaknesses of existing approaches including not doing the project at all.

Software security requirements

A business requirements analysis is not enough to ensure that a system meets the real needs of its users or that it will ever succeed in the real world as a product. In fact, reducing a system specification to a set of required functions, without regard to how the functions are used or how they will be implemented in real hardware/software by real people is a guarantee for failure . The design of a new system or major change will usually involve the following steps:

• Task Decomposition – Business requirements are broken down and mapped into software and hardware modules and features.
• User stories– A “user story” corresponds to a feature of a system module. Stories are small, typically limited by an estimate to implement the software for a story by one programmer working for one week. The user story needs to stay in sync with the business requirements – and stay away from gold-plating.
• Data Modeling – Data modeling describes the data elements in the assessed system and the relationships between the data elements. Done in parallel to developing the “user stories” and ensures that the data needed to do the job is on the model.
• User Interface Design – The user interface needs to be considered at an early stage in the software security assessment cycle. Functional requirements are combined with the knowledge gathered about users and contexts of use to provide the most appropriate methods of interaction.
• Incremental assessment by prototyping – Assess a little piece of the system with selected routines and a  UI.  Security assessment prototyping allows vulnerability hypotheses to be tested, with resulting feedback incorporated into an iterative process of software defect reduction. Early prototypes may be purely paper-based to test the design or using a the application to test the software in vitro.