Functional requirements are the development tasks that will BE or PRECISAM be DEVELOPEDRF001 – Product includedRF002 – Change productRF003 – Product ConsultationRF004 – Delete ProductNon-functional requirements understand how premises, performance requirements and limitations, example:RNF001 - The XML file cannot exceed 500kb.RNF002 - Sending files cannot exceed 60 seconds.Although there must be a NEGOCIO REGRA that prevents reaching these borders and limits.

General algorithmHave a field versaoLocal and a field versaoRemota. Test if they are different. If different, you need to update, if not, good are equal, nothing to do.The specific algorithm is:In a given location you only update the field versaoLocal.Raise all records with versaoLocal ! versaoRemota.Each, runs the update processEach, using the data in memory, do versaoLocal = versaoRemota (if download), or versaoRemota = versaoLocal, upload.With timestampsTesting by difference solves the question wrong watches, timezones, summer time. .You still risk generating a local timestamp equal to a remote timestamp. Low risk, but there is. If you use timestamps, place the maximum decimal of milliseconds available.rowversion, UUID, or triggersInstead rely on date/time, use another versioning source. Some banks provide type fields rowversionwhich guarantee for that bank instance will always have a new number, without repetitions, every UPDATE. It's in https://msdn.microsoft.com/pt-br/library/ms182776(v=sql.120).aspx .In the absence of this use functionality https://en.wikipedia.org/wiki/Universally_unique_identifier that language provides.As an alternative, triggers in the bank, which in any UPDATE increments the number versaoLocal of that record.Again, just test by difference to know when to update.

Absolutely not. Security is in general not something that can be verified through testing. As Dijkstra once wrote, "Program testing can be used to show the presence of bugs, but never to show their absence!" This is especially true for computer security. There are a whole bunch of misconceptions embedded in the idea that requirements need to be testable: Wishful thinking. Gee, wouldn't it be nice if all of the requirements I have were easily checkable using some black-box tests? Wouldn't it be nice if I had a pony? Sorry, that's not how reality works. Suck it up and deal with it. I'll put it another way. Have you heard the story of the late-night drunk who lost his keys while leaving the bar on his way to his car? Bystander asks him why he is looking under the lamppost 100 ft away, and the drunk says "that's where the light is". People get like that. We have to remember that requirements analysis is not about what's easy to check. Rather, it's about what we need. It is about the customer's needs. That's why they are called requirements, not achievements. Misplaced expectations. Most developers spend most of their life building features. If you want to check that the feature is present and appears to work, testing is a great way to do that. Consequently, many developers get used to thinking of testing as the way you go about all kinds of quality assurance tasks. But that's narrow-minded, blinkered thinking. Security is not a feature. Features are about ensuring that good things happen when the user asks for them to. Security is about ensuring that bad things never happen when the user wasn't expecting them. You can't verify security with feature testing. Put another way, security is about ensuring there are no surprises, when there is a malicious adversary out there poking at your system in unexpected ways. Testing is about poking at the system in expected ways, and consequently doesn't tell us very much about what happens when the system gets poked at by an adversary. Thinking that testing is all there is to quality assurance. Ensuring that a system will be secure is in some ways a quality assurance problem. When it comes to security assurance, testing often isn't the right tool for the job. Security demands different methods. Some of the methods that are most appropriate to checking whether a system is secure and meets its security requirements tend to involve: threat analysis, architectural security analysis, security code review, application of static analysis tools, fuzzing, and penetration testing. Folks who aren't familiar with the security domain tend to be unaware of these methods, or don't realize the important role they play in evaluating the security of a complex software system. Gary McGraw likes to call penetration testing a "badness-ometer". It's a meter with two extremes: on one end, "Your Security is Really Bad", and on the other hand you get "Don't Know". It can never tell you your security is good; it can only deliver bad news, but the absence of bad news does not mean you have good security. There are some security requirements that can be verified through testing: primarily, "security features". But security is about a lot more than just security features. Software assurance is fundamentally different from security features. Example: One plausible requirement is "the system should contain a way to reset my password". That's a feature, and one that can be reasonably checked with testing. On the other hand, another plausible requirement is "the password reset feature should not endanger security". That's a security assurance requirement, and no way you're going to be able to check it with testing. So, no, security requirements aren't necessarily testable. There are plenty of security requirements that cannot be easily checked for compliance using testing; other methods are needed. P.S. Last word: You must read Bruce Schneier's essay on security assurance. It's exactly on target. Schneier points out that we often think about security the wrong way: we start out by assuming the system is secure, until proven wrong. Schneier points out that this is backwards. He suggests that if you want your system to be secure, a better way is to start by assuming it is insecure, until proven otherwise. (And, I'll interject, testing ain't gonna be terribly useful at proving a system is secure. Just a fact of life)

For my company at least, full-disk encryption isn't seen as adequate for 'data at rest' requirements, as on a live system the data can de accessed without providing a key or any additional authentication information. When relying on FDE, if an attacker was able to get in, at that point it's extremely easy to steal data, and do so quickly as no other knowledge is required. We require that all data at rest be encrypted with AES (by various means) or via PGP, without regard to the use of FDE. This way just having access to a running system isn't sufficient to retrive protected data; additional knowledge (passwords, keys) are required. We do require FDE on any system that leaves our facilities, but more to protect ancillary information that could help an attacker (email, notes, etc.) or any information stored in violation of policy.

An example is the content scrambling system to prevent DVD's being copied. While the scrambling system was unknown, this worked. Then a teenager called Jon Lech Johansen figured it out, wrote DeCSS and it was broken. As @GrahamLee points out, security mechanisms which need to be relied on must still work even when known about by the bad guys. These days Cryptography provides security in so many applications, so it is critical that it be implemented correctly. Because the mathematics is beyond most people, there is one school of thought which advocates publishing the algorithms and letting people the world over try to find flaws. The upside - many eyes. The downside - if the algorithm is already implemented, an attacker may find a flaw and be able to use it, so doing this before implementation is very useful. The other viewpoint is to hide the algorithm to prevent attackers knowing how it works - The problem with obscurity is that it has been proven time and time again that relying on security through obscurity fails because at some point the bad guys discover the secret. Worth reading this post by Bruce Schneier - a well known opponent of security through obscurity, and the author of various crypto algorithms which have been tested by the community - as an example of where obscurity has worked, but only because criminals did not learn of the plan. I don't know if it is possible to really answer the last part of your question without more context. For example, if this is for code developed by 3rd parties you could demand a code review, but what you could really look for is a 3rd party that publishes their algorithms / code etc as open source.

Testability is the key, and certainly helps get the QA teams buy-in if they have something to test to. I have a slightly twisted viewpoint on requirements, as I like the idea of anti-requirements. Most requirements state what the system shall/can/may do. Anti-requirements specifically state things that the system should not do, and sometimes it is useful to think that way and capture those. e.g. there tends to be requirements along the lines of The system shall have a mechanism for expiring passwords after a period of time. Though there is rarely the anti-requirement The system shall not be accessible through the use of an expired password. but it is implied in the first.

It's not a violation per se. I think it puts them and their equipment "in scope" for your PCI compliance efforts. Ask your QSA for clarification if you are unsure.

Unless you mean something very specific by "state machine model", there is no reason why you couldn't model conflict of interest using a state machine. The Chinese Wall itself can be easily represented as a state-machine, following the traditional BLP approach: a state is defined by the set of current accesses, a function associating each object to a company dataset, and a function associating each company dataset to a conflict-of-interest class. The transition function takes a state and an access, and if the access request is not in conflict with a current access, it is added, otherwise the access is denied. Ravi Sandhu actually proposed an enforcement of the Chinese Wall model using a lattice-based model, and some of my PhD work was to define some general state-machine model for access control systems, including the Chinese Wall. The section 3.2 of this paper can give you a formal definition of the CW using a state-machine. I hope that helps, and I can bring more clarifications if wanted.

As @Lucas said, a lawyer should be your first port of call, however from a high level I can give some guidance on areas to look at - these are a small subset: How does the organisation test their own security? Do they use approved testers, internal teams, or both? Will you have a right to audit using your own staff or consultants? How do they manage incidents, vulnerabilities and exceptions? Will you have visibility of incidents, vulnerabilities and exceptions during the development lifecycle? Do they use a framework such as OpenSAMM? What responsibilities do they retain after delivery? How rapidly can they respond to advisories, whether from you, a CERT or a vendor? Do they have an escrow agreement in the event of financial collapse? Who will own the code - could it end up being published without your approval? How do they screen or check their employees prior to employment? Within what jurisdiction do they operate? And so on... Get a lawyer who knows this stuff!

It all depends on the the software development method you choose as some methods are more risk management driven than others; but in general, each method has a set of activities gathered under the name of RMP (risk management plan) that can be divided into: Risk identification Qualitative risk analysis Quantitative risk assessment Risk response planning Risk monitoring and control These activities are present during the whole software life cycle. As for the security mechanisms and techniques you asked about, they generally take place during the design phase.

Security Specification is a subtitle in a SRS(Software Requirements Specification) report. Search "security" keyword in this sample SRS report to get better understanding: http://www.cse.chalmers.se/~feldt/courses/reqeng/examples/srs_example_2010_group2.pdf Example specification from that document: ID: QR12 TAG: CommunicationSecurity GIST: Security of the communication between the system and server. SCALE: The messages should be encrypted for log-in communications, so others cannot get user-name and password from those messages. METER: Attempts to get user-name and password through obtained messages on 1000 log-in session during testing. MUST: 100% of the Communication Messages in the communication of a log-in session should be encrypted. Communication Messages: Defined: Every exchanged of information between client and server.

Client bugs are bugs residing in client side programs used to connect or interact with the server: Client: Either software that runs locally on a single computer or software that accesses shared resources provided by a server over a network. Server: Computer that is configured to run software that awaits and fulfills requests from client processes that run on other computers. The difference between client and server side code depends on where the code is executed. So either in the client program or in the server. Your example can cover both server and client-side bugs: Server doesn't offer MiTM prevention through (for instance) SSL Client doesn't verify the certificate prior to setting up an encrypted tunnel It can even be a combination of both server and client side code.

A lot of confusing terms and language here. For correct information risk language, please consider FAIR, or Factor Analysis of Information Risk The terminology "Threat modeling" was correctly replaced by Cigital with the term "Architectural Risk Analysis". Using `threat' here is especially incorrect. Risk assessment (e.g., OCTAVE, OCTAVE Allegro) is also very different from Risk analysis. A risk assessment is a documented, point-in-time questionnaire at best. A risk analysis can be much more useful when the input variables are selected and formulated correctly. By "useful", I mean that they reflect reality closer to what a human can correlate and fit to normalized patterns. Without invoking the book, "Software Security Engineering: A Guide for Project Managers", I can tell you that security requirements engineering, as you request, is not a clearly-defined problem to solve in cyber risk. Many document-heavy projects based on Waterfall or other lifecycle prescriptions were abandoned in Information Technology and Application Development circles in the late 1990s. Today, our practices and value chains are aligned towards Scrumban, the most-modern evolution of xp. If you can follow the FAIR model, then you'll understand how information risk will fit into your organization. This exists outside of your business processes -- it's a standard language to communicate with the multitude of players who could show up to the cyber risk conversation. Threats, as in TCom and TCaps, are an important piece of the FAIR model, so you must quantify threats in order to quantify risk. You must also understand the business. If you identify a vulnerability, or a control-set issue, then you will want to elicit root cause. Root cause is never a patch -- it's always back to the business process, typically consequence management or even crisis management. If you want to see how you can truly fit these pieces together, I suggest you do check out FAIR, but integration is key -- and OpenSAMM makes that integration cleaner than anything else I've seen. If you need a strategic map to forecast your future outputs (or collect the right input variables in the first place), then OWASP OpenSAMM can be fit to any cyber risk need. You'll see the correct language around "security requirements engineering", "threat assessment" (your risk analysis), "design review" (your threat modeling), and much more explicitly defined and explained within.

The nuance is subtle and not well-defined, but if you really want to make a distinction between misuse and abuse, then I'd say that abuse is "misuse with malicious intent". E.g. running while carrying a powered chainsaw is misuse; doing so on purpose in a crowded mall is abuse.

I'd say that there is nothing per se which would always lead to outsourced software being less secure than an in-house development but there are some common factors which may in practice lead to this commonly being the case Cost concerns. If a key factor in winning the work is low cost, then the risk of insecure software is likely to increase. Whichever way you cut it good software security costs money (IIRC Microsofts early SDL estimates was a 10% overhead), so where a 3rd party has to be cost competitive to win, non-functional aspects of the project (e.g. security may suffer). This leads to the second point. Failure to adequately describe the required security level in the contract. A general problem with outsourcing is that the requirement has to be clear in the contract. Things which aren't in the contract are likely not to be focused on (see point 1). Specifying exact requirements for security in a software contract is hard. Language like "it should be secure" isn't prescriptive enough to produce a good result, and the contracting company and outsourced provider are likely to have a very different idea of what "secure" is. "Market for Lemons". Along with that you have the general problem that in secure development there's a market for lemons. What's meant by this is that it's very hard for a buyer to adequately assess the security practices of a development company. There aren't really any good qualifications that can be assessed and buyers are unlikely to go to the effort of manually assessing the security knowledge of the individual developers. All that said, I'd say that it's entirely possible for an outsourcing company to produce more secure software than an in-house team, the key would be for the buying company to actually prioritize security in a meaningful way during the purchase process, take efforts to assess the claims of the bidding companies, and have good descriptive security requirements in the contract.

Reasons to use HTTPS: Encryption: As @mah's comment says, HTTPS traffic is difficult to read and / or change by a man-in-the-middle. Verification of Identity: An SSL certificate is proof to the user that the content being served is actually coming from the server it purports to be. In other words, HTTPS not only encrypts the information but also tries to guarantee that the server that the user is talking to, is truly the server they think it is. If your client's site is HTTP, a competitor or other party could fake the web site entirely so that the user is really talking to some other website and it is easy to imagine ways to abuse the customer of a company you don't like with a web site you control. Man-in-the-middle is not even needed then. To me, this is a good reason to use HTTPS in your case. If the attacker tried this with against an HTTPS site, the browser should raise an alarm. These days, those alarms are difficult for the web user to not notice.

It's quite an odd question, since stakeholders and/or sponsors usually fund and initiate projects. If the stakeholders are unknown, and you have no customer party to talk to, I don't think you have a project at all. But "methods for communication" with stakeholders - we have a lot. In the 1990's and before that the waterfall project methology was popular. It ment that you defined a scope into great detail and didn't meet each other again until delivery. The methodology have since the early millennium been abandoned, since the customers where unhappy, the consultants where unhappy and it was expensive. Today the ruling project methodology is Agile. You divide the project scope in one to four week sprints, where you define the scope in the beginning, and show a demo in the end of each sprint. The customer writes use cases for each new sprint, and adds things they where unhappy with in the previous sprint. By using this methodology, customers are happy, consultants are happy and the project meet budget on time. But it does not guarantee that the original scope of the agreement is met, just that the customer are happy with the current solution they get (i e pay their invoices).

The user experience will suffer if you make it a past-input check. Users enter content, probably write a bunch of lines and get a message about how it isn't okay after they did all the work, this leads to a bad experience. So you have to display the potential errors on-the-fly. Like "Still 100 words to go" Also, you should consider analyse what high quality is. A generic text input field with "write all your stuff here and let it be >500 words" probably won't lead to good quality. If you found out what kind of informations are needed, you can split it up in a few input fields with semantic differences, with each having some restrictions.

You could carry out a mini ethnographic study, it is great that you have the opportunity to observe the users in their real-world environment. It is worth looking at: What they do How they use things What they need Information that would be great to gather include things like, contextual interviews, examples of other devices that they use and maybe some video/photographs (if possible). I agree with what greenforest has said, you are not there to undermine them merely to see how the embedded device can be improved and actually help them more to do their jobs. Maybe see if you can get a small focus group together with a white boarding session, simple questions like "Best things about the device", "Worst things", "Features you wish it could have". Be careful to speak to the actual users and not the 'managers' you want to know real users thoughts. And take criticism on the chin, it can be hard to hear sometimes!

"Elaborate on functional requirements" is not a good place to start the elicitation. The users don't know their own requirements (even when they think they do), and besides, you should be trying to get the non-functional requirements at the same time. I am accustomed to work with Ian Alexander's requirements elicitation approach, and it has given good results so far. The UX expert should take part in all the stages, although he is most active in the scenario stage. In all of the others, his job is to act as the users' advocate, and defend their interests because the other discussants (usually engineers and management) often forget to take the user perspective in account when making decisions. Stakeholders Do not forget to list them all, or you will miss important requirements. The UX designer will need some information about the stakeholders who directly interface with the system, basically he needs to know their background so he can guess at their expectations. He might want to create personas at this stage. Goals I find it easiest to do them concurrently with the stakeholders who have them. The UX designer will have to keep them in mind, but is unlikely to need information beyond what is already important for getting the FR. Context, interfaces, scope Here you want to know the "landscape" in which the system will run, both the software landscape and the organisational context. You have to define which functions will be done by your own system, which ones by other systems, and which will stay manual. The UX designer does not have to do much here, but he needs to jump into the discussion if the others discuss solutions which are very hard on the user, e.g. requiring the user to manually enter information into interfacing systems. Scenarios Here is where you get your tasks defined. The UX specialist should be the one guiding this discussion, as he is usually the person with the best understanding of how the users will interact with the system. After the scenarios are gathered, it is the UX specialist's job to create the "workspaces" - a description of all the data and functions a user will need for completing a task. Later, an architect can create a data model based on this description, and the UX specialist can use it for designing actual screens. The above can be gathered in the sequence specified above. There are other types of information which are needed in a complete requirements specification, and in my experience, they crop up all the time during the above steps. Qualities and constraints are what most people think of when they hear "non-functional requirement". Just about everything specified in the good old ISO 9126 falls into that category. This includes classic usability metrics, such as "95% of non-trained users should be able to complete task X in less than 3 minutes". I have rarely seen a real-life project which specifies on this level of detail, but if it does, then this is what concerns the UX expert at this stage. Rationale When you make a decision, it is a good idea to document why the decision was made that way. Nothing specific to UX here. Most people don't bother doing it at all, I normally do it for politically controversial decisions, or when a decision is made based on a counterintuitive argument which was discovered accidentally. Definitions A glossary for the project. Software engineers have the unfortunate tendency to understand a concept, think of it in their own terms, then use these terms in all kinds of design documents, and the system ends up with those terms exposed in the user interface. All too often, it happens that these terms are not the ones users are familiar with, and the system is very hard to fathom for them. It is the UX specialist's job to pay attention that the most important domain terms are recorded (and used throughout the project) in the language of the domain, not in the language of the engineers. Measurements Here you define the acceptance criteria for the project. Frequently not elicited at all, but if they are, the UX specialist should of course pay attention to ones concerned with the UI. Priorities The requirements obviously have to be prioritized. The UX expert has about the same role as other specialists here, mainly to not let the most important requirements from the user's point of view be swept under the table. You asked "what questions should the UX expert ask". As you see, even the definition of what the UX expert has to achieve in each stage is rather long. How do you know what question to ask about each? First, an intelligent person with the right attitude can figure out their own questions once they know what information they need to end up with (yes, it is hard, but it gets better with experience). Second, there are books on requirements engineering, from which the UX expert can learn. In my experience, the combination of Discovering Requirements by Alexander and Beus-Dukic, and User interface design by Lauesen gives you a very solid foundation for creating specifications for a system with good user experience.